Hi, Alexander. Sorry for the late reply, but I had to do some research. :)
On Mon, 2 Jun 2003, Alexander Gr�fe wrote:
>I have just noticed a problem with bincimap.
>My boss has a considerably large IMAP spool (over 800 MB), spread over a
>lot of nested directories.
>Now when he accesses it over squirrelmail, it takes a long time for any
>folder related action (showing the folder list, collapsing a folder,
>etc.)
>With courier, there was no noticable lag, even with such large volumes
>of mail. Has anybody else experienced this problem, or maybe even a
>solution? I really don't want to go back to courier ;-)
Thanks for your feedback!
Binc IMAP's MIME parser is slower than Courier-IMAP's parser today. There
are several reasons for that, all of which will be dealt with. It should
be a requirement that an is-not-courier IMAP server stays within a certain
percentage of Courier-IMAP's performance ...even better - it could be
faster.
The focus of the ongoing work on Binc IMAP today is on the
Depot->Mailbox->Message API and design in general, and we're working on
getting the backend completely replaceable. The first proof-of-concept
implementation of this might be a NNTP plugin-module or support for Cyrus'
mail storage.
The MIME parser today is at least two-pass at most three-pass with regards
to running fgetc() on the same character in the same file multiple times.
This is the greatest performance killer. So we have that and a few more
things we could improve to make the MIME parser faster:
1) Design a single-pass parser
\_ Never read the same byte twice from the file system
2) Add lazyness to the parser/Message design
\_ Never parse any more of the document than what is needed, for
instance, if someone asks for BODY[1], then stop parsing after
the boundary for part 1 is reached.
3) Introduce indexing of the documents
From this project's philosophy, the enhancements are listed in my order
of preference, since neither 1 or 2 involve any fancy code - just good
design.
Item 3 will boost performance for partial fetches, but considering the
actual performance gain compared to the amount of code involved to get it
to work, I would put it up as a lowest priority.
Regards, Andy :-)
PS: How much slower could you say that Binc IMAP is compared to
Courier-IMAP on the mailboxes you speak of? Is it 1-2-3 times
slower?
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | Nil desperandum
