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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
