Fixed one memory leak in complex objects #537
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…le a new class in that case.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are actually two memory leaks: one is in Uproot. This one is due to the fact that ROOT instance versions can sometimes be
0while the class version is something else, and Uproot was repeatedly redefining the class, which was both slow and contributed to global memory (because they're new classes). The commit in this PR fixes that (checks for instance version0and no matchingknown_version, tries maximumknown_versioninstead).The other memory leak is in NumPy: numpy/numpy#6581 (comment)
If you follow the thread back, people have been talking about it since 2009 (SciPy ticket 1003, ported to GitHub in 2012, superceded by the above issue in 2015, and there's an open PR numpy/numpy#15065, last touched in 2021).
We have NumPy object arrays with cyclic dependencies because (at least)
STLVectorand friends have NumPyvalues, which can sometimes be objects (because it's ROOT data), and those objects can point to themselves through_parent. I don't like the idea of the STL collections sometimes being NumPy (when they're numbers) and sometimes not (when they're objects), and a quick attempt at implementation led to instant test failures, so no. Too many design decisions were based on the idea that a NumPy object array is just a fancy Python list (including not having memory leaks, like a Python list). Maybe some of these objects don't need to have_parent? What about cyclic references through the Cursor'srefs? Either way, it's getting messy quick.Of course, if NumPy's bug gets fixed, no changes would be needed in Uproot. Ideally, that's what ought to happen.