On 10 Sep, 2007, at 15:18, Andi Vajda wrote:
On Mon, 10 Sep 2007, Brian Kirsch wrote:
It would be a good idea to focus a discussion thread solely on
Chandler 1.0 mail support. To me right now the biggest
barrier to Chandler being a full fledge IMAP client is performance
and memory foot print. Isolating the mail object to
Item conversion and commit in a MailWorker thread for Preview
really highlighted the performance deficiency.
Really ?
I thought that a decent mail rendering and composing UI was the
biggest barrier.
With a fast connection,The Chandler Mail Service can download and
process 6,000+ messages before the
first 1,000 messages have been committed including notifications
fired, observers called, and mail
indexed. That is a big discrepancy. There is a lot of redundancy
in the notification and observer logic
which needs to be examined closely.
True but how often does someone have to download 6000 messages ?
1000 messages ?
Isn't the day-to-day use of email, with a few new messages every
connect a more reasonable number to look at ? Is that also
currently too slow ?
Yes, that is a more reasonable number, (although you need to make
sure that users can import large amounts of email in a "finite"
length of time). I'm more concerned about Chandler's memory/disk/CPU
usage with, say, 75,000 total mail items in the repository (a number
I took from my current mail client ... others may vary).
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
