Speaking of performance...

We really do need to attack the startup performance somehow, for
people (like myself) with big collections.  I currently have a little
over 300,000 shots in my collection, and depending upon how well we do
in the postseason that could increase by another 10% over the next few
months.  It takes about 13 seconds for kpa to start up, largely due to
the XML parsing.  Since the XML file is "only" 57 MB, it's clearly not
I/O-limited.

I understand (and agree with) the desire for a readable and editable
file format.  I've fixed things up myself on occasion.  But I don't
want to pay that kind of startup price every time.

What I'm thinking in terms of is to save the file in two formats, a
fast format (which could be an SQL database, a binary serialization,
or such) and the XML format.  The fast format would have an embedded
timestamp; if the XML file were newer, it would be used instead, or
the user would be prompted to choose which.

Autosave would save only the fast format (possibly only a delta, but
that would likely be quite difficult).  Full save would save both
formats; if we were really clever, we might be able to parallelize the
two operations.
-- 
Robert Krawitz                                     <rlk-FrUbXkNCsVf2fBVCVOL8/[email protected]>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton