Re: [Evolution-hackers] mmap() for the summary file
On Mon, 2006-06-19 at 11:56 +0200, Florian Boor wrote: > as long as we talk about individual senders this is true, but if you think > about > mailinglists and all this automated server notifications this could save > quite > some memory. As long as it is possible to implement this without a too big > effort and code overhead it would be useful. Of course - even saving 100kb > which > would be optimistic for a huge mailbox is not be worth to mention on a modern > PC - but on a mobile device that would be nice to have. But the complexity for getting this *in* the file that is to be mmap'ed does increase then. Also the backward compatibility is undoable this way. You'll need to implement some sort of hash-table with pointers to strings at the beginning of the file, hash-keys in the summary tree itself. And the strings at the end of the file. Agreed that this would dramatically increase loading time (the time needed to seek/walk-a-pointer over the entire mmap()ed file and create summary-info structs). As it would decrease the amount of data that is to be mmap()ed. I agree this is worthwhile for the current "read() to memory" implementation. I don't think the complexity is going to payoff in real improvements for a mmap() implementation of it. But I would, nevertheless, be very interested in the experiment. Note that there's an mmap() on Windows and that glib abstracts it with some glib API. I would of course use the glib abstraction API for this. -- 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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mmap() for the summary file
Hi, [EMAIL PROTECTED] wrote: > H... I am not really convinced yet; I mean even when I have > 100 mails with the same email address in my Inbox (which seems > a lot from one person!). The email-address would be 20 chars; now having > 'm all in one string saves me, even in this extreme case, only > about 2Kb, event forgetting about the overhead of the hash tables etc. as long as we talk about individual senders this is true, but if you think about mailinglists and all this automated server notifications this could save quite some memory. As long as it is possible to implement this without a too big effort and code overhead it would be useful. Of course - even saving 100kb which would be optimistic for a huge mailbox is not be worth to mention on a modern PC - but on a mobile device that would be nice to have. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: +49 271-771091-14 and the reality of tomorrow.Fax: +49 271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 1D78 2D4D 6C53 1CA4 5588 D07B A8E7 940C 25B7 9A76 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
RE: [Evolution-hackers] mmap() for the summary file
Hi Philip and others, >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of ext >Philip Van Hoof >Sent: Sunday, June 11, 2006 16:56 >To: evolution-hackers >Subject: [Evolution-hackers] mmap() for the summary file >I've been trying to replace the fread()/fopen() implementation >in camel-folder-summary.c with an mmap() one. > >I know camel-file-utils.c will put duplicate strings in a >hashtable and that way reduce memory usage for the summary >information. Because a lot mail boxes have duplicate strings >for the From and To headers. I know why and how this is >implemented. And I understand that this already reduces memory >usage a lot. H... I am not really convinced yet; I mean even when I have 100 mails with the same email address in my Inbox (which seems a lot from one person!). The email-address would be 20 chars; now having 'm all in one string saves me, even in this extreme case, only about 2Kb, event forgetting about the overhead of the hash tables etc. >However. On a small device with few memory resources, the >kernel knows better when to allocate and when to deallocate >uncachable data like this summary information. > >Therefore I propose to replace the implementation with mmap(). >Not only I propose it, I also already tried it myself. [ string proposal ] Sounds good :-) >But anyway ;) What about having an camel-session at GUADEC, to see what people's ideas are etc.; recently, it seems more and more people are using camel directly (without evo), it would be good to sit down and see how we can streamline this stuff. Best wishes, Dirk. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
