Re: [Evolution-hackers] ... and how camel should be

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2006-02-14 at 11:06 -0500, Jeffrey Stedfast wrote:

> > Imagine spastic users that do nothing but scroll all day long at
> > extremely rapid speeds .. multiply that with 10.000 such users, and you
> > still wouldn't have any problems at all.
> 
> Even for single-user, disk-summary-branch was slower than the current
> in-memory implementation.

Which is of course nothing but pure logic. Memory will always be faster.
But also more expensive. Using to much memory makes evolution less
scalable.

And the current disk-summary-branch might or might not be the final
implementation of something like this.

> Now scale this to many hundred users all accessing the same disk and you
> will notice a much larger impact on performance because there will be a
> lot more disk seeks compared to just single-user.

Not per definition true. An operating system these days is pretty smart
about caching of slower block devices. And I don't know how the current
implementation is like ...

... but if a database like sqlite and mysql-embedded can give me 100.000
records in a few seconds, from disk, I don't think it has to be "per
definition" slow. In contrary. Using such an engine might be a possible
component, why not?


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be