Re: DecoderPro panel cleanup

Svata Dedic
 

Dne 09. 10. 19 v 18:26 Bob Jacobsen napsal(a):
Separating the XML is also a good idea. One of the causes (but not the only one!) of the large memory footprint of DecoderPro with some large files is retained JDOM2 information. It’s been hard to track that down, as JDOM2 has a complicated retention model internally. Having well separated XML-read and functional code should help with that.
Then the 'separation' should be extended to RosterEntry and PaneProgFrame as well: A quick scan in a heapdump shown that there are not many Content JDOM references referenced from individual PaneProgPanels (this is what I've refactored), but that the Frame keeps them for some reason. RosterEntry as well.
If those do not load content lazily / partially on-demand, they shouldn't keep Element refs after initial phase.

-S.

Join jmri@jmri-developers.groups.io to automatically receive all group messages.