You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When items are repeatedly added to and removed from new trees, the symbols stay and start clogging up the memory. Don't know if this is necessary by design or not.
This was indeed by design because it was the fastest solution for jsdom's use case. In jsdom objects are often removed from the SymbolTree and then added back a little while later. (Also note that jsdom uses a finite amount of SymbolTree instances). Deleting and then adding back the property would be slower, and also delete may cause deopts in v8.
Would it help if I added an option to the constructor?
consttree=newSymbolTree({cleanup: true});tree.remove(someObj);// which would then trigger `delete someObj[this.symbol]`
And then jsdom could continue to use the {cleanup: false} behaviour.
That would be a good solution, yes. If delete is bad in these cases, I'd just recommend setting it to null if that makes a difference.
But if it's by design, don't feel pressured on my part. Turns out I can't use this awesome lib anyway, unfortunately, since it can't allow the same object multiple times. Just thought I'd mention the problem since I already wrote the test and thought somebody might one day run into the problem ;)
When items are repeatedly added to and removed from new trees, the symbols stay and start clogging up the memory. Don't know if this is necessary by design or not.
My simple test:
The text was updated successfully, but these errors were encountered: