Re: [Evolution-hackers] ... and how camel should 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

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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]