Am Montag, den 04.12.2006, 14:42 -0800 schrieb Robert Burrell Donkin
> My local fork has wandered quite a way away from the JAMES base: I gave up
> running the test suite on my personal fork quite a while ago. The code wasn't
> really intended to be a serious proposal. just what works for me.
So what are the most itching issues you have fixed in your local branch
that aren't in trunk? Maybe we can bring them a bit nearer.
Apart from that you could check out a second instance of trunk to be
uptodate with recent changes. This way you could try out and test your
ideas with valid results.
> The STATUS issue is so large when using evolution that it renders JAMES IMAP
> unusable for anyone other than developers. it basically takes 10 minutes to
> open the client even with the relatively small volumes of data I have
> currently (probably < 5000 messages).
> Any speed up would be great but i fear that something more radical may be
> needed. Evolution sends a STATUS every couple of minutes for every visible
> mailbox.
In fact the current intended audience are only developers because it is
experimental.
Did you try out the recent changes I made to TorqueMailbox?
IMO this should solve the worst problems. Opening a session with 1000
messages took about 1000 ms. Okay that is also quite slow.
The join logic inside Torque is not well optimized.
(It uses a nested loop instead of a HashSet which causes n(n+1)/2
iterations)
I reimplemented the join logic and opening of 10000 messages needs about
1000 ms now.
> If the hack above sounds risky then perhaps it would be wise to consider
> altering the MailboxManager API. Perhaps pass through a parameter object
> (MailboxConfiguration, say) with mailboxName as a property something like:
>
> public interface MailboxManager {
> ...
> ImapMailboxSession getImapMailboxSession(MailboxConfiguration
> configuration) throws MailboxManagerException;
> ...
> }
> Then a 'readOnly' property could be added to the configuration object. Given
> that the mailbox is not used for writing then it should be safe enough to
> postpone loading the cache until needed. STATUS command (and any other
> similar ones that happen to have performance issue) could set this property
> to true. This would isolate the potential impact of not caching on init().
Opening a session readonly could be an enhancement for the future but I don't
think that it's the solution for this problem.
It would also be possible to put getNumberCache() at the top of all needed
methods of the SessionWrappers.
I prefer reviewing the whole number cache thing and running tests before making
any decisions concerning changes to the API.
At the moment I consider 1000 ms for 10000 messages as reasonable.
Which similar ones have you got in mind?
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
