Re: nnimap slowness

[Simon Josefsson <jas@extundo.com>]

David Abrahams <dave@boost-consulting.com> writes:

>> I guess it doesn't come with source.  I recall the same problem was
>> identified quite some time ago, but perhaps it was never reported
>> upstream.  Asking the vendor to optimize the SEARCH commands for flags
>> is probably the only practical solution then.
>
> My sysadmin says:
>
>     I'll ask about this in CommuniGate mailing list, but I think that
>     implementation of IMAP SEARCH in CGPro is correct. This is a quote
>     from press release:
>
>     The POP and IMAP components of the CommuniGate Pro server not only
>     support the latest Internet standards and all not-yet-standardized
>     protocol extensions, but they also allow for simultaneous
>     symmetric access to mailboxes. The high performance of IMAP
>     built-in search engine results in huge benefits for individuals
>     and organizations dealing with multi-thousand-message mailboxes.

There is nothing wrong with the implementation, specification wise,
but if the server is slower to search for a read flag on a 100MB
article compared to searching for a read flag on 1KB file, the server
could be optimized.

>     I think that problem is in our server - it's 650Mhz AMD with IDE
>     hard drives.
>
> But I'm suspicious that it's not the server since other mail clients
> don't seem to have any particular problems with speed.

Few (if any) other clients use the SEARCH command like Gnus does, so
they don't trigger the same problem.