Can we improve performance of mutations in Persistent mode?

[tonypee]

Currently, i have a map which stores info about many thousands of images. The code path is generic, so that i can respond to HDD events, or a scan. But it means that each image requires calling a 'set' command on the map, which in turn requires cloning the while tree if i have persistence turned on.

Would it make sense that the clone of the tree actually occurs asynchronously, as the events do?

Or, the 1st mutation, could cause a shallowClone of the tree, and later mutations could simply mutate - as you already have a new object. You would need to check equality of the node that you are mutating, to see if the parent is already mutated, and cause a mutation if it isn't (you are mutating a separate part of the tree).

Would this sound like an appropriate performance optimization?

[abacaj]

Wouldn't baoboa just batch your sets, where you can force a commit (update event) after? Which means in one action call if you update several paths then that boils down to one tree update.

[Yomguithereal]

This was how transactions were handled in earlier version but was dropped for two reasons: 1) performance was not better, 2) this was confusing as a get after a set would not return what the user would expect (plus it was a nightmare code-wise to withhold two different states at the same time).

This said, when performing costly updates, one can use either higher abstractions (example: using a merge rather than several sets when updating an index) or clone the object once, mutate it and reset it at the end of the operation.