On 18 Jul, 2006, at 17:33, Bryan Stearns wrote:
Travis Vachon wrote:
Bryan, one other note: you mentioned at one point that you could
put a
commit back in after stamping happens. This seems to make sense,
and if
there are no objections, it would be convenient for me to have
this happen.
Travis,
The objection comes from the performance tests: stamping will get
even slower. As it is, the 3000 event calendar stamping test takes
200% of the current goal. Last time I tried, it took me more than
three days work to find a way to make it about 15% faster, and I
don't know of anything else to rework to improve it further.
I could cheat and reduce the apparent impact of this during the
automated tests by forcing a commit before the timing starts, but
it'll still be a fair bit slower than it is now, and I'm unable to
do this with the current goal. (This is cheating because the user
will still see the stamping operation include all the time to
commit anything the user has done since the last commit - it'll
look even slower still!)
In general, when does the UI commit changes?
Although committing after every user operation has a significant
performance downside, there are reliability advantages (*):
1) Less chance of data loss if the app/user's machine crashes
2) Data is reasonably up-to-date in background sync operations
--Grant
(*) Maybe these are beta-quality reliability constraints, though.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
