On Sun, 26 Feb 2006 23:00:47 +0100, Leonard Bouchet roundcube@alternative.ch wrote:
Hi,
On 26 févr. 06, at 15:05, Thomas Bruederli wrote:
Mark Edwards wrote:
Having a quick look at message_index in program/include/rcube_imap.inc it appears that it returns an array of the index data for the whole mailbox. Why is this necessary to retrieve the UID for two messages? Surely there is a better way to do this?
If you find one, please let me know...
Could you test the attached patch? It basically does 2 things:
- If sorting is in default mode (date_DESC) or disabled, just use
IMAP's message sequence number to get the next and previous unique IDs. This should be really fast compared to what was done before.
- If the user sorts the message's list, only do a ' UID SORT' command
instead of 2 ' SORT' and ' FETCH' and get the next and previous IDs from the returned array. I'm not totally convinced this will really improve performance, but may deserve a try. We could also improve things caching the resulting array in the session while we display the list, but I'm not really sure it's a good idea, due to inconsistencies it may add.
It seems to work for me, let me know if it does for you ... and make a backup before applying the patch, you never know :)
It works great for the most part on my end. Very fast now to view a message in a large box, no different than a small box. With the one exception that if the message list is sorted by something other than date_DESC, its pretty much as bad as before -- i.e. total failure on a large box.
I still don't get why it is able to produce the index so quickly no matter what. Why can't the same indexing method be used for both making the main index of a box, and finding the prev/next UID's?
But good job, its much improved. We're almost there.