thanks to hyatt, I have a performance optimization for multiple message
delete.
The optimization is to use the tree batching api.
If you have a tree, in JS, you can do this:
tree.treeBoxObject.beginBatch()
// do stuff
tree.treeBoxObject.endBatch()
In between beginBatch and endBatch, the tree will not redraw and will
not scroll. When endBatch is called, the tree will do the right thing.
(perhaps hyatt can provide more techincal details.)
If you were to delete 20 messages from a folder with 1,000 we'd unassert
on every message we delete. This would cause us to reflow and scroll 20
times, which is very expensive.
My fix is to call beginBatch() when we call delete with more than <n>
messages, and then when the delete is complete, call endBatch().
(<n> is not determined yet. we might have to think about computing it
based on the number of messages to delete and the number of messages in
the folder.)
we still unassert on ever message we delete, which causes us to destroy
content, which is expensive. But at least we aren't spending as much
time in reflow as we were.
As hyatt points out, random access enumerators are the way we eventually
need to go.
My wall clock timings are very encouraging. I'll finish up the fix, and
report back with some actually numbers.
-Seth
