Re: Upcoming Cache Work

On 1/24/2012 5:39 PM, Patrick McManus wrote:
> Nick - its an awesome list you have!
>
> I've been keeping an evernote with some ideas about this - so let me
> just dump my notes out here in their unfleshed-out glory as input to
> your project. They might not be helpful to you - I won't be hurt, but I
> did want to share them. I'll admit some of this is thinking-big instead
> of just fixing a weakness but if its an area we can leap frog ahead
> surely that's worth discussing.
>
> * Reduce random access nature of I/O by replacing with block reads and
> writes that can minimize seek and utilize read ahead.. instead of 1 IO
> event per URI, maybe organize things temporally or by their embedded
> object relationships. I like fifo data structures for this - they are
> great at minimizing contention. Consider if a little duplication of
> smallish things (js) is really so bad if it saves seek times.

I agree with everything that has been suggested(except for the cache 
sharing idea, that can be done in an addon).

We absolutely need to get rid of hashtable-on-disk pattern of cache 
block files. It has insane overhead. As mentioned elsewhere we should 
change the format to instead have better data-locality and readahead.

We should stop assuming that disk cache is faster than network(Bug 725423)

Taras