[YANGTOOLS-1206] Improve model.api.ValueRange$Range usage Created: 20/Jan/21 Updated: 07/Feb/21 Resolved: 07/Feb/21 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | parser |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0 |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Parser Performance |
| Description |
|
ValueRange is a simple construct which works on any java.lang.Number. Examining a heap dump of Junos 19.3 test case reveals we are allocating java.math.BigIntegers to hold ranges – 32428 instances Each BigInteger costs us 64 bytes of memory, even when we could get away with much smaller storage – Integer/Uint32 and Long/Uint64 end up costing 16/24 bytes, hence we could potentially cut memory usage from ~2.5MiB to 500-800KiB. Track down the user and try to persuade it to use smaller Number classes. |
| Comments |
| Comment by Robert Varga [ 07/Feb/21 ] |
|
These turned out to be RangeStatementSupport and LengthStatementSupport. The fix is to properly clamp possible values to the spec – which are built-in integral types for Range and Uint64 for Length. |