[YANGTOOLS-502] DataTree: make LazyContainerNode really lazy Created: 13/Sep/15 Updated: 10/Apr/22 Resolved: 18/Sep/15 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Comments |
| Comment by Robert Varga [ 13/Sep/15 ] |
|
The step from LazyContainerNode to MaterializedContainerNode performs a complete materialization of the children map. This leads to potentially a large number of entries being created when only a single one is modified – especially for containers with large number of leaves and keyed maps. This process can introduce a stall in case of large maps, as the number of entries needing processing can be in the 100K range. This is also inefficient for MapEntryNodes, where we instantiate key leaf nodes – but those are typically not modified. Rename LazyContainerNode to UnmaterializedContainerNode and its place introduce a real LazyContainerNode, which will perform materialization in an incremental fashion when a child is actually modified. This should be done by first consulting the children map. If an entry is found, it will be returned. If it is not found, it needs to be created, stored in the map and then returned. The Mutable#seal() implementation should check if the size of the data children matches the number of stored child nodes. If it does it should create a full MaterializedContainerNode, eliminating the child lookup overhead. |
| Comment by Robert Varga [ 14/Sep/15 ] |