[Chandler-dev] Chandler Performance: Who's doing what
bkirsch at osafoundation.org
Fri Apr 13 15:25:21 PDT 2007
I am currently profiling the message text to Chandler Item conversion
code in osaf.mail.messages as
improvements here can significantly increase download performance.
This work is part of [Bug 7177] Improve mail download performance and
I am in the process of writing performance tests for the following
1. Downloading a EIMML Message
2. Downloading a EIMML Task
3. Downloading a EIMML Event
4. Downloading a EIMML Recurring Event
5. Downloading a EIMML Task / Event
6. Downloading a MailStamp item from the Chandler Mail folder
7. Downloading a TaskStamp item from the Chandler Tasks folder
8. Downloading a EventStamp item from the Chandler Events folder
9. Downloading a message containing a .ics Event
10. Downloading a message containing a .ics Recurring Event
11. Downloading a message containing a .ics Task
12. Downloading a message containing a .ics Task / Event
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
On Apr 13, 2007, at 12:16 PM, Reid Ellis wrote:
> The two things I'm looking into are MultiStateBitmap and gradient-
> drawing. There are wx updated for the latter that may provide some
> On Apr 12, 2007, at 20:56, Grant Baillie wrote:
>> Here's a brief summary of what I think people are (and have been)
>> up to during the first few days of our performance tri-week (or
>> fortnight-and-a-half). Most of it is gathered from IRC, mailing
>> lists, and in-person conversations. Mostly, this email is so that
>> everyone has a vague idea of what everyone else is working on, so
>> that work doesn't get duplicated.
>> * If I've omitted or misrepresented stuff you're working on, feel
>> free to send out corrections.
>> * Also, if you have grand (but implementable :) performance ideas
>> that no-one is looking at, now would be a good time to suggest them.
>> But first, some ...
>> + Andi and Bryan came up with two groovy improvements in indexing
>> + When an item's position in a sorted index needs to be
>> (typically, because some attribute that contributes toward a
>> sorted index has changed), first check if it needs to be moved
>> at all by comparing it with its left and right neighbors.
>> It turns out this saves a lot of compare() calls when an
>> triage-related information changes, because triage attributes
>> are used in all the Dashboard's indexes, but only as a
>> sort key (for breaking ties) in most of the columns.
>> + Allow for caching of attribute values in MethodIndex compare()
>> calls. This is a win because calculating an item's position
>> in an
>> index takes O(log2(n)) compare calls, but the expensive
>> part of the
>> compare is looking up each of the two uuids's attribute
>> Since the same uuid will be an argument to compare()
>> multiple times,
>> it's a win to remember its values.
>> + Heikki noticed a regression in "new" style sharing as compared
>> to what we had before, and he, Andi and Morgen tracked it down to
>> a change in the use of some repository API (mapHistory() vs
>> + John's Block notification refactoring seems to have had a good
>> effect on performance numbers
>> + Andi
>> - Has been looking at profiles of import and new event creation.
>> - Has been working with Bryan
>> - Rewriting often-used pieces of repository python code in C.
>> - Next up: calendar overlay performance?
>> + Bryan (Stearns)
>> - Wrote a new performance test for the "Triage" button, and
>> worked with
>> Andi to reduce the time considerably.
>> + Grant
>> - Looking at getting rid of the effectiveStartTime (computed)
>> which we seem to spend a fair amount of time calculating.
>> - Looking at the problem of having to change (and eventually
>> commit) 70
>> birefs every time you change selection in the detail view.
>> + Heikki
>> - Removing stray usage hotshot.Profile.runcall() from
>> performance tests.
>> - General perf test maintenance.
>> - Profiling startup performance.
>> - Comparing "old" and "new" style sharing performance profiles.
>> + Jeffrey
>> - Looking at reducing the amount of drawing and calculation in the
>> calendar when events change. (possibly in conjunction with
>> John's work
>> + John
>> - Reworking the Block dirty and hints mechanism. As of the α5
>> Blocks have no way to avoid marking themselves dirty when the
>> item they
>> are displaying changes, which leads to excessive
>> synchronization. In
>> addition, the existing hints mechanism involves Blocks keeping
>> in memory
>> a lot of unneeded information (essentially, a history of all
>> received since the last sync)
>> + Morgen
>> - Mostly busy doing sharing interop work with cosmo; but wrote
>> to obfuscating personal data for use in tests, and another to
>> a hotshot profile for reload (as in "dump and reload") of a
>> data set (derived from the Office Calendar, I believe).
>> + Philippe (Bossut)
>> - Looking at some wx drawing optimizations.
>> + Phillip (pje)
>> - Investigating reload performance, disk space permitting.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev