'emerge -pev @world --backtrack=0 --usepkg=n' seems to take a huge amount of time to complete here (dropping the backtrack and/or usepkg param doesn't make a difference). This problem started recently, as in the past, it would take ~10s or so. If I revert 9206d5a75ecd2d9ae0fe63e57d28aa8061b5927e ('find_smallest_cycle: Increase ignore_priority to find smaller cycles'), then it completes quickly again.
I haven't tried to analyse this (yet) with a profile or getting a backtrace or anything. I'm going to get the --debug output for both first.
Created attachment 875266 [details] emerge -pev @world --usepkg=n --debug (xz-compressed)
Created attachment 875267 [details] emerge -pev @world --usepkg=n --debug (xz-compressed) (with revert)
Created attachment 875268 [details] emerge --info
(In reply to Sam James from comment #2) > Created attachment 875266 [details] > emerge -pev @world --usepkg=n --debug (xz-compressed) This one took > 10 minutes, while the revert was done in seconds.
Seems like we need to find some way to terminate the ignore_priority loop earlier than 9206d5a75ecd2d9ae0fe63e57d28aa8061b5927e does. With search terminating at len(smallest_cycle) == 1, it probably has to search through every ignore_priority quite often.
We might make gather_deps abort early if the number of selected_nodes meets or exceeds the size of the current smallest_cycle.
(In reply to Zac Medico from comment #7) > We might make gather_deps abort early if the number of selected_nodes meets > or exceeds the size of the current smallest_cycle. That's what https://github.com/gentoo/portage/pull/1187 does, and on my laptop where emerge -pe @world takes about 10 minutes, with this patch it took about 43 seconds less than it did with portage-3.0.55.
We'll have to revert the change from bug 917259 since it was not optimal and it was far too expensive. I've updated https://github.com/gentoo/portage/pull/1187 to include the revert. On my laptop, this brings the emerge -pe @world time down to 3m40.081s, compared to 10m44.268s with portage-3.0.55.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=cdc781349337fa755bc15773e2a87e4b41f5ff1e commit cdc781349337fa755bc15773e2a87e4b41f5ff1e Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2023-11-22 21:46:12 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2023-11-22 22:26:13 +0000 Revert "find_smallest_cycle: Increase ignore_priority to find smaller cycles" This reverts commit 9206d5a75ecd2d9ae0fe63e57d28aa8061b5927e. The len(smallest_cycle) == 1 loop termination condition is not optimal and it's too expensive as reported in bug 917660. Bug: https://bugs.gentoo.org/917660 Bug: https://bugs.gentoo.org/917259 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/_emerge/depgraph.py | 7 +++---- .../tests/resolver/test_alternatives_gzip.py | 7 +++++-- lib/portage/tests/resolver/test_merge_order.py | 24 ++++++++++------------ .../tests/resolver/test_rebuild_ghostscript.py | 6 +++--- 4 files changed, 22 insertions(+), 22 deletions(-)
