[GH-ISSUE #4] Change tracking improvement #5

New issue

Closed

opened 2026-05-23 08:25:05 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-23 08:25:05 -06:00

Owner

Originally created by @appy-one on GitHub (Jan 29, 2021).
Original GitHub issue: https://github.com/appy-one/acebase/issues/4

Originally assigned to: @appy-one on GitHub.

The code that does change tracking currently clones the entire previous stored value to prepare previous/new values to trigger change events and index updates with. Because change events might be on higher paths than the data being updated, cloning the data costs memory and cpu, while most of it isn't even changed. Even worse, it also does this when target data is being deleted. It would be better to create shallow copies of the original data (new objects whose properties point to the existing in-memory child objects), and recursively shallow copy the data up to the path being changed, only changing that data. Tracking changes this way is also faster because most properties will point to the same data as the previous value's properties, eliminating the need to traverse the tree to find changes - they'll point to the same data: previous.someObject === current.someObject

Originally created by @appy-one on GitHub (Jan 29, 2021). Original GitHub issue: https://github.com/appy-one/acebase/issues/4 Originally assigned to: @appy-one on GitHub. The code that does change tracking currently clones the entire previous stored value to prepare previous/new values to trigger change events and index updates with. Because change events might be on higher paths than the data being updated, cloning the data costs memory and cpu, while most of it isn't even changed. Even worse, it also does this when target data is being deleted. It would be better to create shallow copies of the original data (new objects whose properties point to the existing in-memory child objects), and recursively shallow copy the data up to the path being changed, only changing that data. Tracking changes this way is also faster because most properties will point to the same data as the previous value's properties, eliminating the need to traverse the tree to find changes - they'll point to the same data: `previous.someObject === current.someObject`