RE: Storing partial responses

On Wed, 13 Dec 2000, Robert Collins wrote:

> Hmm. Well I am definately heading to a (2) approach, because
> performance tuning will need both FS and meta level activities.

        It is not clear to me which approach yields better performance
in practice. Essentially, you are comparing RISC approach (small set
of very basic/simple but fast commands) with, EISC(?) (extended set of
very sophisticated/complex but slow commands).

        An orthogonal example would be the delegation of
responsibilities between hard drive controllers (fast operations on
semantic-less easy-to-handle blobs/blocks) and Unix file systems
(relatively slow operation on files). One could argue that if disks
knew more about files, they would perform "better".

        In other words, sometimes it is better to keep the lower
levels of the design fast and simple, while making slow but smart
decisions at the meta-level. You do loose efficiency because of the
communication between the layers, but you gain in overall design
flexibility, which often proves more important, even performance wise.

> (2a) optional support: I think this is the way to go. Not for time
> to stabile so much, but because it's 'free'. It's free because if
> the FS won't store partial objects, then the meta level code can
> simply always consider the store to have a MISS on that key.

I agree.
 
> when you say fair but slow I presume you mean development time not
> performance?

Exactly.

Alex.
Received on Tue Dec 12 2000 - 22:20:03 MST