The recent addition of these lines resulted in a big performance boost:
20:from functools import lru_cache
13:from functools import lru_cache
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.
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.