On 29/07/2010 11:05, A.L.E.C wrote:
http://lists.roundcube.net/mail-archive/users/2010-07/0000021.html
I'm not sure all of you are reading users list. THREAD preformance issue has been fixed. Still on big mailboxes it can took a few seconds for handling threads. BTW, my proposition to make displaying messages (in 'show' action) faster is to create page navigation (#countcontrols) in separate (ajax) request after message.html page is loaded. Any thoughts?
I have had a quick squiz at the code and it seems to me:
- We need threading when retrieving the inbox list
- But.. imap THREAD results are also retrieved when opening the email
view - it's not clear why it's needed here?
- It seems like we need to know something for the Next/Prev buttons to
work, but why not restructure those to be an ajax call like "Fetch('next',UID)" so that the "next" in order email is looked up only at the moment we click, rather than looking it up (possibly needlessly) for every email? This seems to be a big win?
- Further it appears that if you only wish to find the Next / Prev email
from a given message then there is a shortcut possible. The THREAD results are in depth first order so we don't need to parse them to move next/prev, we simply find the current UID in the list and then find the next id either before or after? So where we are using the THREAD simply as an ordering then we can simply locate the ID and move a few characters each way
- It's also not clear why a SORT is done when the message view is
shown? Presumably this is part of the same thing as above? However, surely we only need one or the other? Can we optimise and avoid retrieving unneeded data here?
- I'm presupposing here that the threads are returned in the correct order?
For reference when I open the message view, but the inbox list is presented in "Thread" sort order then the following IMAP commands are sent to the server (dovecot 1.2) - it seems like we are getting more data here than we strictly need?:
[27-Jul-2010 14:18:51 +0100]: S: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5] MailASail Mail Server Ready. [27-Jul-2010 14:18:51 +0100]: C: a000 AUTHENTICATE CRAM-MD5 [27-Jul-2010 14:18:51 +0100]: S: + xxx [27-Jul-2010 14:18:51 +0100]: C: xxx= [27-Jul-2010 14:18:51 +0100]: S: a000 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in [27-Jul-2010 14:18:51 +0100]: C: cp01 CAPABILITY [27-Jul-2010 14:18:51 +0100]: S: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS [27-Jul-2010 14:18:51 +0100]: S: cp01 OK Capability completed. [27-Jul-2010 14:18:51 +0100]: C: sel1 SELECT "INBOX" [27-Jul-2010 14:18:51 +0100]: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded $MDNSent $Label1 $Label4 $label5) [27-Jul-2010 14:18:51 +0100]: S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded $MDNSent $Label1 $Label4 $label5 *)] Flags permitted. [27-Jul-2010 14:18:51 +0100]: S: * 33208 EXISTS [27-Jul-2010 14:18:51 +0100]: S: * 0 RECENT [27-Jul-2010 14:18:51 +0100]: S: * OK [UNSEEN 5911] First unseen. [27-Jul-2010 14:18:51 +0100]: S: * OK [UIDVALIDITY 1154000160] UIDs valid [27-Jul-2010 14:18:51 +0100]: S: * OK [UIDNEXT 52570] Predicted next UID [27-Jul-2010 14:18:51 +0100]: S: * OK [HIGHESTMODSEQ 871] Highest [27-Jul-2010 14:18:51 +0100]: S: sel1 OK [READ-WRITE] Select completed. [27-Jul-2010 14:18:51 +0100]: C: FH12 UID FETCH 52569 (UID RFC822.SIZE FLAGS INTERNALDATE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-PRIORITY X-DRAFT-INFO)]) [27-Jul-2010 14:18:51 +0100]: S: * 33208 FETCH (UID 52569 RFC822.SIZE 2886 FLAGS () INTERNALDATE "27-Jul-2010 14:18:29 +0100" BODYSTRUCTURE (("text" "plain" ("charset" "ISO-8859-1" "format" "flowed") NIL NIL "7bit" 279 10 NIL NIL NIL NIL)("text" "html" ("charset" "ISO-8859-1") NIL NIL "7bit" 993 24 NIL NIL NIL NIL) "alternative" ("boundary" "------------050604020001020900020202") NIL NIL NIL) BODY[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-PRIORITY X-DRAFT-INFO)] {286} xxx email here xxx
[27-Jul-2010 14:18:51 +0100]: S: ) [27-Jul-2010 14:18:51 +0100]: S: FH12 OK Fetch completed. [27-Jul-2010 14:18:51 +0100]: C: thrd1 THREAD REFS US-ASCII ALL [27-Jul-2010 14:18:51 +0100]: S: * THREAD (16082)(24693)(414)(28356) ... .... 33K results here .... .... ..... [27-Jul-2010 14:18:51 +0100]: S: thrd1 OK Thread completed. [27-Jul-2010 14:18:51 +0100]: C: s SORT (ARRIVAL) US-ASCII ALL [27-Jul-2010 14:18:51 +0100]: S: * SORT 6738 6737 6740 .... ... 33K results here .... ... ...
I haven't yet re-profiled the code (xdebug seems helpful), but Alec suggested that a lot of CPU is spent in rcube_imap_generic::parseThread() - Just eyeballing that it seems like this could be done without the recursion - this seems like it could be a win?
Thanks
Ed W
List info: http://lists.roundcube.net/dev/