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
