Worst case scenario, handling more than a few incrementals should only happen when the monitor is starting for the first time after the patch has been applied; with conjunction with the other patch, that should be the last time it does so.

After a sync we would only have to rebuild multiple full maps iff the monitor sharing its state happened to be on a version prior to this patch being applied, but that's pretty much the same conditions as above.

But implementing what Greg suggested couldn't hurt.  Is not as if having a transaction slightly bigger is going to make much difference anyway (we already perform 1MB transactions by default when synchronizing) and if that has a chance to reduce the time spent on IO all the better -- although I'm not sure that will help that much on the leveldb side, considering it will first write to the log and then apply the changes to the store, but on the shorter term it might help relinquishing the current thread to progress with the task at hand.