The recent addition of these lines resulted in a big performance boost: lib/portage/dep/__init__.py 20:from functools import lru_cache 402:@lru_cache(1024) lib/portage/versions.py 13:from functools import lru_cache 111:@lru_cache(1024) 309:@lru_cache(10240) The values 1024 and 10240 were chosen for some trade-off of speed and ram usage. However, with 64 gigs of ram, my trade-offs might be different than your trade-offs. Therefore, I propose a user-configurable scaling knob, PORTAGE_LRU_CACHE_SCALING_FACTOR. These would then be used like: @lru_cache(1024 * PORTAGE_LRU_CACHE_SCALING_FACTOR) This way, users with excess ram could trade it for a performance boost. Reproducible: Always
We can hook this into the portage.data._init(settings) function which is used to initialize things with user configuration settings.
In https://bugs.python.org/issue24969 there's a rejected proposal to allow runtime resize of lru_cache instances, with rationale give that a lru_cache instance has a __wrapped__ attribute which can be used to unwrap and re-wrap the wrapped function. A disadvantage of the function re-wrapping approach is that it would not be possible to replace all previous imports of the wrapped function with new lru_cache instance, so we would need to add an additional decorator to serve as a layer of indirection for cases when the wrapped function has been imported into another module. However, I expect the performance impact of this extra decorator layer to be negligible.
