[YANGTOOLS-493] Enumeration codec does not canonicalize values Created: 04/Sep/15 Updated: 10/Apr/22 Resolved: 13/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 |
||
| Description |
|
L2FIB scale test analysis has shown we end up with a lot of duplicate strings in the heap – around 12MiB for 400K l2fib entries. All these strings are retained as a value of an enumeration leaf. Enumeration's allowed values are known in SchemaContext, and EnumStringCodec already uses this information to validate incoming strings when it is available. This makes it possible to perform String canonicalization with little overhead, which would result in elimination of duplicates when data is being introduced from outside of the system (such as via NETCONF/RESTCONF). |
| Comments |
| Comment by Robert Varga [ 04/Sep/15 ] |
| Comment by Robert Varga [ 07/Sep/15 ] |
| Comment by Robert Varga [ 07/Sep/15 ] |