Garbage collecting or compressing custom OptionTrees

[jlstevens]

Currently when a style customization is applied, one or more custom option trees are added to the Store object. These option trees persist and accumulate until the kernel is restarted after which point they can be added again by either running the customizations again or via unpickling.

Creating an OptionTree is cheap and each tree doesn't consume much memory. Nonetheless, we have no way of eliminating unused trees (i.e garbage collection) or of compressing identical trees together. This is particularly an issue using DynamicMap where you can easily generate an unbounded number of option trees.

Some ideas of how this might be addressed are discussed in the PR introducing styles to DynamicMap (#368). In short, it would be possible to use tree comparisons to keep only unique trees and store only the associated ids (compression). Garbage collection is harder as you would probably need to find the set of all ids currently applicable in the namespace to find out which option trees are no longer in use.

[philippjfr]

Do we still think this is an actual problem in practice? After having worked with them for >2 years now I don't think the size of option trees is a particular concern.

[jlstevens]

Right, I don't think it is a problem in most cases why this issue concerns a low priority feature rather than a bug...

[philippjfr]

I don't think we should keep features we have no intention of ever implementing around, it's just clutter.

[jlstevens]

It is still a potential memory leak though you would probably need a huge number of option trees before it would be a problem. Anyway, as it hasn't been a problem in practice I will close this issue.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.