Re: [Evolution-hackers] Reviewing imap_update_summary

2006-10-23 Thread Sankar P
On Sun, 2006-10-22 at 15:41 +0200, Philip Van Hoof wrote: Greetings, imap_update_summary is implemented in three or four steps: o. Getting (all) the headers/uids o. Finding the ones that we must still fetch o. Fetching those (x) o. Writing out the summary The steps each

Re: [Evolution-hackers] Reviewing imap_update_summary

2006-10-23 Thread Philip Van Hoof
On Mon, 2006-10-23 at 04:02 -0600, Sankar P wrote: Hey Sankar, Thanks for the response. I rewrote this behavior in camel-GroupWise to fetch data in iterations, so that the memory requirement remains a constant k instead of O(n), n being the number of messages. I expected it work better. (GW

Re: [Evolution-hackers] Reviewing imap_update_summary

2006-10-23 Thread Philip Van Hoof
With UID FETCH %d:%d FLAGS being something not all IMAP servers don't correctly support, I was a little bit forced to rewrite the imap_update_summary function into these two ones: I also simplified it a little bit. And removed one of the two/three GPtrArrays (that are being synchronized and

Re: [Evolution-hackers] Reviewing imap_update_summary

2006-10-23 Thread Philip Van Hoof
On Tue, 2006-10-24 at 01:56 +0200, Philip Van Hoof wrote: static guint32 imap_get_uids ( { ... while ((type = camel_imap_command_response (store, resp, ex)) == CAMEL_IMAP_RESPONSE_UNTAGGED) { ... if (size 0)

[Evolution-hackers] Reviewing imap_update_summary

2006-10-22 Thread Philip Van Hoof
Greetings, imap_update_summary is implemented in three or four steps: o. Getting (all) the headers/uids o. Finding the ones that we must still fetch o. Fetching those (x) o. Writing out the summary The steps each consume memory and reuse some of the memory of the previous step. Pointers

Re: [Evolution-hackers] Reviewing imap_update_summary

2006-10-22 Thread Philip Van Hoof
On Sun, 2006-10-22 at 15:41 +0200, Philip Van Hoof wrote: In the code I have found no real reason to why this was done in separated loops (steps) rather than one step and at the end of the loop, free the data already. Especially for the third step (x), which seem to consume most memory while