Re: [Evolution-hackers] Memory consumption and virtual machines
- From: Federico Mena Quintero <federico ximian com>
- To: Jeffrey Stedfast <fejj novell com>
- Cc: evolution-hackers gnome org, desktop-devel-list gnome org, Philip Van Hoof <spam pvanhoof be>
- Subject: Re: [Evolution-hackers] Memory consumption and virtual machines
- Date: Tue, 18 Jul 2006 16:05:08 -0500
On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote:
> I have to wonder if it's even worth ever merging the mmap hack into
> Evolution at all. If the plan is to finish Zucchi's disk-summary branch,
> which also solves the memory problems (afaik) as well as:
>
> 1. introducing an API for using cursors to get at message infos
> 2. better designed on-disk format that uses B-Trees
Let's put that discussion on Pause until someone actually starts
resurrecting the disk-summary branch.
If Philip's patch turns out to work well for daily use, it may be a good
stopgap measure. The disk-summary branch will need way more QA time
than the mmap() stuff, and a lot more performance tuning work as well :)
> the problem with philip's mmap file format is that the strings that will
> be hit for sorting/viewing/etc are all spread out over a huge number of
> pages. I just see this being re-examined later to try and design the
> format to better optimise it by compacting all the strings into a strtab
> type thing.
I've been talking to Philip on IRC, and gave him these requirements for
his patch:
1. Don't change the external ABI of Camel, so that Evo needs no changes,
*OR* also submit a patch to update Evo for the changed API.
2. Make sure the summary format on disk works with older Evos without
making *them* rewrite the summaries. This is for deployments which have
machines with old and new versions of GNOME, but NFS homedirs accessible
from any machine.
3. Keep the coding style, variable naming convention, indentation, etc.
It may be possible to change the summary format by *just* adding a
nul-terminator to strings; that may work with older Evos if we are lucky
enough that they'll just ignore the nul byte at the end. This needs
testing.
I'd say that (1) and (2) are hard requirements. (3) is the usual stuff.
> I just don't get the feeling this is really all that well thought out
> and it scares me.
>
> I'd just hate to see a rush job come out of this
Yeah, it needs good testing. Philip says he'll cook a patch so that I
can use it with my system's e-d-s RPM for daily use. Then I can test it
with my normal mailbox.
Federico
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]