All new items added via adapter operations end up in DOM

I believe in current implementation if you add items via append / prepend / applyUpdates operations on adapter all those new rows would end up being added to buffer / inserted to DOM / get all the watchers created for, etc, which basically leads to sluggish / unresponsive UI when added set of data is relatively big.

It's easy to change some of the demos to add bunch of items (i.e. 1000) instead of one to reproduce (i.e. http://rawgit.com/armortext/ui-scroll/master/demo/adapter/adapter.html), even though it might require higher number of watchers per row to see the effect visually, but you can inspect it in dev tools.

I'm wondering if those adapter operations can be changed to process new data in micro-batches where buffer is adjusted after smaller number of buffer modifications and addition of new elements to the buffer is avoided if they are clearly going to be out of bounds for items that should stay in the buffer?

It can be partially addressed / avoided for items that would be prepended / appended if the datasource is bounded and we can simply update datasource minIndex / maxIndex instead of calling prepend / append. Unfortunately it seems there are some issues with maintaining scroll position and top / bottom paddings when items are of variable height that becomes known only after item template is bound to the data. Also, it does not solve it for case when bunch of items are being inserted via applyUpdates.

The best workaround in current implementation that I see so far is to capture topVisible index and simply reload data if there is a chance that it's relatively big number of newly added items, but it's quite suboptimal from visual perspective, and also complicates code quite a bit if you try to be minimize number of reloads like those.

Any thoughts?