Re: [Evolution-hackers] ... and how camel should be
- From: Lee Revell <rlrevell joe-job com>
- To: Philip Van Hoof <spam pvanhoof be>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] ... and how camel should be
- Date: Tue, 14 Feb 2006 13:02:21 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]