-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, March 21, 2006 11:13, Marc Groot Koerkamp wrote: >>>> I agree with this last statement. The backend has a _lot_ to do >>>> with this issue. We use an NFS appliance for a backend that we were >>>> experiencing problems with (high latency) that caused the same >>>> issue with large mailboxen. >>> So if i'm understand right: You are working on this issue? >>>> After correction I can open a maildir mailbox with >>>> 40,000+ messages successfully (after about 2 minutes). >>> The opening is not an issue in this 20Kbox it opens (and sorts)in >>> about 20secs to 2min. Threading is another question it took 5-6mins. >> That would be because just doing a normal sort/display doesn't involve >> any work on the part of SquirrelMail to be honest. Threading is >> something entirely different. Threading returns a formatted string of >> message ids that then needs to be processed and the message information >> from the server. This is two seperate IMAP calls. The first returns >> data that looks like this: [..] >> These IDs then need to be passed onto the code that fetches the message >> information. This list of IDs is potentially enormous, especially in >> folders that have 20k messages (that's 20k message IDs that need to be >> returned). > Theoraticly it involves the parsing of around 12 bytes per message (10 > bytes for representing the max value for a 32 bits int and 2 bytes for a > space and of a paranthesis) which is around 240KB which is about the same > amount of data that has to be processed when we parse the sort response > (only the parentheses are not part of the short response). Practically > the amount of data to be parsed is shorter because normally the imap > server does not return 10 byte string representations for uid's. Theoretically you are correct, the amount of data is roughly the same. Practically I believe you are wrong. SORT uses a preg_split (we could probably change that to explode for speed), while THREAD checks byte for byte for special characters. The code execution on SORT is pretty quick (one command), while the code execution on THREAD has to loop through a long list of values, checking for ( and ) and the numbers between to build the thread. At least in stable anyway. > Personally i don't think that the parsing of the thread response is an > issue in 1.5.1 because that part is rewriten the week before we released > 1.5.1. The reason for the rewrite had to do with the incapability of > parsing large threadresponses in the previous thread parse code (which is > the same as we use in 1.4.x). Having a quick look at the code, it just appears to be a tidy version of what is in stable, it is still looping through the THREAD response, looking for ( and ). So I'm not sure, haven't tested. Might be an ideal candidate for my dev laptop and profiler :) - -- Jonathan Angliss <[EMAIL PROTECTED]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iEYEARECAAYFAkQgUFgACgkQK4PoFPj9H3NJ2wCgqb23aHqwX2jH2pj/yR1k7zp6 TAwAn0deIlqmWAGV2IZS+Xs9CuJLMKcv =5ALJ -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 -- squirrelmail-users mailing list Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines List Address: squirrelmail-users@lists.sourceforge.net List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
