Hello,
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
repository storage.
I am in the process of writing performance tests for the following
cases:
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
-Brian
Brian Kirsch
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org
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
improvements.
Reid
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 ...
Successes
---------
+ Andi and Bryan came up with two groovy improvements in indexing
performance:
+ When an item's position in a sorted index needs to be
recalculated
(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
item's
triage-related information changes, because triage attributes
are used in all the Dashboard's indexes, but only as a
secondary
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
values.
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
mapHistoryKeys())
+ John's Block notification refactoring seems to have had a good
effect on performance numbers
Activity
--------
+ 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)
attribute,
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
below).
+ John
- Reworking the Block dirty and hints mechanism. As of the α5
milestone,
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
notifications
received since the last sync)
+ Morgen
- Mostly busy doing sharing interop work with cosmo; but wrote
scripts
to obfuscating personal data for use in tests, and another to
generate
a hotshot profile for reload (as in "dump and reload") of a
large-ish
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
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
