load_repo: main cure for memory leak
This brings down the leaking over 1000 requests from 55MB to about 5MB. We are not yet forcing garbage collection (as `hgwebdir` does). The `_filteredrepotypes` keeps a correspondence between unfiltered repository classes and the filtered version. The problem is that each new repository is an instance of the single-usage class generated in `hgext3rd.topic.reposetup`, so these accumulate in `_filteredrepotypes`. Ironically the mapping seems to be there to avoid some other case of leaking: ``` # Python <3.4 easily leaks types via __mro__. See # https://bugs.python.org/issue17950. We cache dynamically created types # so they won't be leaked on every invocation of repo.filtered(). _filteredrepotypes = weakref.WeakKeyDictionary() ``` One could imagine that garbage collection of the repo would also just clear its reference from the `WeakKeyDictionary`, but it doesn't happen. A final suprise is that this unlocks the collection of `ui` instances. According to investigation made with `guppy3` the class objects were actually the ones eating the most memory, but getting rid of `ui` instances is also good news.
parent
e15ae399
No related branches found
No related tags found
Please register or sign in to comment