> I didn't analyze the results, but could the problem be orderable child > nodes? Currently, oak-core stores a property ":childOrder".
no, the problem is how oak-core detects changes between two node state revisions. for a node with many child nodes in two revisions, oak-core currently loads all children in both revisions to find out, which child nodes were added, removed, changed or didn't change at all. I'm currently working on this issue in KernelNodeState by leveraging the MK.diff(). right now it simply checks if there are differences, but doesn't make use of the information. this should bring the cost down to O(N) where N is the number of modified child nodes. Please note this requires a correct implementation of MK.diff()! Regards Marcel
