Every now and then there’s the question, how many child nodes are supported in JCR. While the technical correct answer is „there is no limit“, in practice there are some limitations.
In CRX 2.x the nodes are always ordered. In CRX 2.x even unordered nodes are treated as if they are ordered, which made the difference nearly to non-existent. [Thanks Justin for making this clear!] This means, that the order needs to be maintained on all operations, including add and remove of sibling nodes. The more child nodes a node has, the more time it takes to maintain this list.
But for the aspect of reading nodes there is no impact on performance. So it is not a problem to have 6000 nodes in /libs/wcm/core/i18n/en, because you only read the nodes, but you don’t change them.
But nevertheless this „limit“ can be cumbersome, especially if you don’t need to the feature of ordered child nodes. Also the fact that there is this limit means, that adding you have the impact (at a a lower level) also already with less nodes.
With Apache Oak this has changed. With Oak nodes are not ordered unless its parent has node type which supports ordering.
To illiustrate the difference between sling:folder (no ordering required) and sling:orderedFolder (ordering required), I did a small test. I wrote a small benchmark to create 5000 nodes, then add more nodes, do random reads and delete them afterwards. For every operation a single node is created or deleted followed by a save(). (Sourcecode)
|Create 5000 nodes||6124 ms||17129 ms|
|Random read 500 nodes||2 ms||9 ms|
|Add 500 nodes||112 ms||564 ms|
This small benchmark (executed on 2014 Macbook pro with SSD, AEM 6.0, TarMK, Oak 1.0.0) shows:
- Adding lots of child nodes to a node is much faster when you use a non-ordering nodetype
- Also random read is faster, obviously Oak can use more efficient data structures than a list, if it doesn’t need to maintain the ordering.
The factor of 3-4 is obviously quite significant. Of course the benefit is smaller if you have less child nodes.