I finally got a chance to try Sid's lru_cache suggestion, and the results were really good. Simply adding it on catpkgsplit and moving the body of use_reduce into a separate function (that accepts tuples instead of unhashable lists/sets) and decorating it with lru_cache gets a similar 40% overall speedup for the upgrade case I tested. It seems like even a relatively small cache size (1000 entries) gives quite a speedup, even though in the use_reduce case, the cache size eventually reaches almost 20,000 entries if no limit is set. With these two changes, adding caching to match_from_list didn't seem to make much/any difference.
The catch is that lru_cache is only available in Python 3.2, so would it make sense to add a dummy lru_cache implementation for Python < 3.2 that does nothing? There is also a backports-functools-lru-cache package that's already available in the Portage tree, but that would add an additional external dependency. I agree that refactoring could yield an even bigger gain, but hopefully this can be implemented as an interim solution to speed up the common emerge case of resolving upgrades. I'm happy to submit new patches for this, if someone can suggest how to best handle the Python < 3.2 case. :) Thanks, Chun-Yu On Mon, Jul 6, 2020 at 9:10 AM Francesco Riosa <viv...@gmail.com> wrote: > > Il 06/07/20 17:50, Michael 'veremitz' Everitt ha scritto: > > On 06/07/20 16:26, Francesco Riosa wrote: > >> Il 29/06/20 03:58, Sid Spry ha scritto: > >>> There are libraries that provide decorators, etc, for caching and > >>> memoization. > >>> Have you evaluated any of those? One is available in the standard library: > >>> https://docs.python.org/dev/library/functools.html#functools.lru_cache > >>> > >>> I comment as this would increase code clarity. > >>> > >> I think portage developers try hard to avoid external dependancies > >> I hope hard they do > >> > >> > > I think the key word here is 'external' - anything which is part of the > > python standard library is game for inclusion in portage, and has/does > > provide much needed optimisation. Many of the issues in portage are > > so-called "solved problems" in computing terms, and as such, we should take > > advantage of these to improve performance at every available opportunity. > > Of course, there are presently only one, two or three key developers able > > to make/test these changes (indeed at scale) so progress is often slower > > than desirable in current circumstances... > > > > [sent direct due to posting restrictions...] > yes I've replied too fast and didn't notice Sid was referring to > _standard_ libraries (not even recent additions) > > sorry for the noise > > - Francesco > >
