| Summary: | Regression in dependency resolution times for --emptytree | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Sam James <sam> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | flow, gentoo, kostadinshishmanov |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=917259 https://github.com/gentoo/portage/pull/1187 https://bugs.gentoo.org/show_bug.cgi?id=918682 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 916977 | ||
| Attachments: |
emerge -pev @world --usepkg=n --debug (xz-compressed)
emerge -pev @world --usepkg=n --debug (xz-compressed) (with revert) emerge --info |
||
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(-) |
'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.