Seth Spitzer wrote:
>
> The optimization is to use the tree batching api.
>
why we can't sync this up with the existing RDF batching API...
basically it goes:
Deleting 5 messages:
* datasource calls: observer->beginUpdateBatch(this)
* Template Builder (an rdf observer) QI's the root (the <tree>) to some
"batchable" interface: element->QI(nsIDOMXULBatchableElement)
* Template builder now calls the tree's batchableElement->BeginBatch();
This way it would all happen automatically, and we wouldn't need any
special JS.
Alec
>
> 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
