On 26/07/2010 14:50, A.L.E.C wrote: > >> Note the delay ONLY occurs when threading enabled on the main message view > So, slow is THREAD or its result parsing. >
Yes, confirmed in the IMAP logs. So my reproducible behaviour is to take vanilla RC beta, connect to a dovecot instance with an inbox containing 33K messages, click the icon top left corner of the message list and choose "Thread" from the view options, very short pause while the list redraws, then finally double click on some small message The imap logs from that point show the imap server very quickly (sub 1 second) return what appears to be the thread info for every message, then a sorted list of the same (sort states completed in 0.102 seconds) There is then a 45 sec (ish) delay before the connection resumes and grabs the message itself and the browser suddenly wakes up and displays the message. During that period the PHP process is wedged at 100% cpu. Then I go back into the message list, disable threading and this time double click on the same message. Now the message displays instantly. Comparing the imap_log I see what appears the exact same set of commands except for the lack of the threads list. It would therefore seem extremely likely that it's the parsing of the imap THREAD results which is causing the delay and high CPU? Interesting that you don't see this? Does your 10K message folder contain any threaded messages? Do you have threading enabled in your message list view? Thanks for any thoughts Ed W _______________________________________________ List info: http://lists.roundcube.net/users/
