GNOME Bugzilla – Bug 331017
Camel needs more possibilities for the developer
Last modified: 2006-09-11 10:04:08 UTC
camel_folder_get_uids o. Possibillity to get an iterator in stead of a large allocation with char pointers It would be doable to use the uids while not having to allocate a lot memory. When I have 10.000 char pointer strings in memory, this becomes a lot for a mobile device. o. Possibility to get the iterator in a specified sort order This would make it possible to simply fetch a new list of message headers upon treeview sorting, rather than letting the Gtk+ standard sorting tools sort the treeview (which is slow because it needs to read each and every header that is to be sorted) CamelMessageInfo - camel_folder_get_message_info o. Possibility to only load specified headers o. A flag that tells me which of these headers are loaded (could be a 32bit field) o. A method to load more headers into the instance These would make it possible to have a treeview that has "only" the visible header strings in memory. Adding a column isn't a frequently requested procedure and can therefore be made slower. It's far more important that less memory is allocated. The only memory that is really needed is the memory used for visible things: For example the subject, from, date, to headers. It should be for example like this: CamelUidIterator* camel_folder_get_uid_iterator (CamelFolder *self, CamelUidSortOrder *sortorder); CamelFolder *folder = ...; CamelUidIterator *iterator = camel_folder_get_uid_iterator (CAMEL_UID_DATE_FIRST_SORT_ORDER); wanted_hdrs = 0; wanted_hdrs |= SUBJECT_HEADER; wanted_hdrs |= DATE_HEADER; wanted_hdrs |= FROM_HEADER; wanted_hdrs |= TO_HEADER; while (iterator) { const char *uid = camel_iterator_current (iterator); CamelMessageInfo *msg = camel_folder_get_message_info (folder, uid, wanted_hdrs); /* Play with msg */ iterator = camel_uid_iterator_next (iterator); }
You can replace the word "camel" with "evolution" in these sentences. Camel design flaws: Camel keeps a copy of all message-id's in memory (camel_folder_get_uids). It would be better if in stead of a GPtrArray, it would return an iterator. It could then keeps those uids on disk. Imagine a folder with 10.000 e-mails (it's not insanely lot, isn't it?). There's very few mobile devices that can handle such large "GPtrArray" allocations. And given the fact that only at most 20 headers are visible in the header summary view, it's totally unnecessary to load all 10.000 message-id's into memory. Camel requires you to do this. Camel reads too much information per such header into memory. For a summary view only the by-the-user selected columns are necessary in memory. For example only the message-id, from, mime-type, subject and date. Camel doesn't make it possible to retrieve the message headers in a sorted way. Therefore the user interface developer needs to use a slow gtktreesortable. Imagine that for sorting, the treeview needs to read all those 10.000 message headers. That's dog slow on a device that needs swap space to store the 10.000 headers in it's virtual memory space. It would be much faster if I could get an iterator that simply gives the ->next in a sorted fashion. Then sorting would simply be assigning a new iterator to the model and letting the treeviews redraw hocus-pocus make it look like sorting actually happened. Only the 20 or so visible rows would be read. The 9.990 others wouldn't.
I have been watching this thread on evolution-hackers. Please remember when considering design of these things, that some of us are running multi-user systems with hundreds of users on at a time. There might be cases where memory is better than disks in such cases. I have hundreds of users and can easily get all of this into 16GB. What will be the result of all of those people now using the disk?
Closing my own bug (aged proposal)