I forgot to mention that I suspect that DeleteSelection is slow because
other threads create a bunch of items on startup (e.g. zaoboa) which add
to the time of the first commit, and if it's DeleteSelection, it's going
to be slower.
John
John Anderson wrote:
Hi Alec:
If we use commit points for undo points, then it typically makes sense
to commit after finishing an undoable operation or commit the last
operation before starting an undoable operation in the UI thread. I
think DeleteSelection is an undoable operation, so I think the commit is
appropriate -- not the refresh.
I suspect the reason the commit might be so slow isn't because of the
items that were deleted by DeleteSelection, but instead, all the other
items that were changed in other threads or as part of startup. So I
think when we're done with startup we should do a refresh in the UI
thread and when other threads have items for us they should notify the
UI thread to do a refresh. This would solve the performance problem if
it isn't the items deleted and make undo possible for not much effort.
However, it's slow because committing the items changed by
DeleteSelection is slow, then the solution isn't to avoid commit, the
solution is to speed up commit.
If this is confusing I'd be happy to go over it on a white board when
we're both at OSAF
John
Alec Flett wrote:
Hey John -
I've got a fix for two bugs in one patch:
http://bugzilla.osafoundation.org/attachment.cgi?id=494&action=edit
The two bugs are:
http://bugzilla.osafoundation.org/show_bug.cgi?id=2322
about switching from commit() to refresh() to gain some performance
http://bugzilla.osafoundation.org/show_bug.cgi?id=2090
about fixing up the column widths when the grid widget is sychronized
Do you mind taking a look? I can explain any of it too but its pretty
small & straight forward...
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
