Current HC list read:

1. takes IDs from VPP
2. reads corresponding DTOs
3. converts DTOs to DataObjects
4. merges DataObjects into parent
5. converts parent DataObject to NormalizedNode using BindingNormalizedNodeCodecRegistry
6. RESTCONF/NETCONF translates NN to XML/JSON

By stream like processing we could shorten lifetime of data representation created in each stage and hence reduce peak footprint.

Possible improvements:

• DataObject representing list element is eligible for garbage collection after converting all list elements to NN. That could be improved by converting DO one by one and merging resulting NN into parent NN.
• GC of VPP DTOs:
  • if readAllIDs and read(id) is available in VPP, then it happens after translating single DTO to DO (A).
  • if only readAll is available then, for performance reasons, we usually store result in ModificationCache. Entries from ModificationCache are not removed until (5). We could delete them entry by entry after converting single DTO to DO (B).
  • There is no reason for changing HC api from readIDs to readAll in case A. In case B, we would also have to store all DTOs (not sure if we change jvpp to provide 'true' streams), but we would not need to create InstanceIdentifiers.
• NN are just temporary representation for XML/JSON produced by RESTCONF/NETCONF. Shortening lifetime of NN would probably require changing the way NETCONF/RESTCONF is initialized in HC (currently w e inject custom DOMDataBroker).