Re: ... and how camel should be

On Tue, 2006-02-14 at 18:57 +0100, Philip Van Hoof wrote:
> 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.

I really don't think the message IDs are the main source of bloat in
Evo.

For starters, how about making glib use a sane thread stack size, like
POSIX says you should, rather than counting on the default to be sane?
Currently it defaults to RLIMIT_STACK which is usually 8MB per thread!

Lee