Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] depgraph._serialize_tasks: improve runtime cycle handling (bug 590514)
Date: Sun, 07 Aug 2016 15:14:57
Message-Id: 20160807081450.2d601261.dolsen@gentoo.org
In Reply to: [gentoo-portage-dev] [PATCH] depgraph._serialize_tasks: improve runtime cycle handling (bug 590514) by Zac Medico
1 On Thu, 4 Aug 2016 21:33:59 -0700
2 Zac Medico <zmedico@g.o> wrote:
3
4 > Previously, it was possible for _serialize_tasks to count some
5 > dependencies of a runtime cycle as part of that cycle, leading to
6 > sub-optimal merge order for these dependencies because they got
7 > grouped together with the cycle in the overall merge order. Fix
8 > it to separate these dependencies from the cycle, and merge them
9 > earlier.
10 >
11 > X-Gentoo-Bug: 590514
12 > X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=590514
13 > ---
14 > pym/_emerge/depgraph.py | 50
15 > +++++++-------- .../resolver/test_runtime_cycle_merge_order.py |
16 > 72 ++++++++++++++++++++++ 2 files changed, 98 insertions(+), 24
17 > deletions(-) create mode 100644
18 > pym/portage/tests/resolver/test_runtime_cycle_merge_order.py
19 >
20 > diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
21 > index fc957f5..26037ad 100644
22 > --- a/pym/_emerge/depgraph.py
23 > +++ b/pym/_emerge/depgraph.py
24 > @@ -7415,36 +7415,38 @@ class depgraph(object):
25 > selected_nodes =
26 > set() if gather_deps(ignore_priority,
27 > mergeable_nodes,
28 > selected_nodes, node):
29 > - # When
30 > selecting asap_nodes, we need to ensure
31 > - # that we
32 > haven't selected a large runtime cycle
33 > - # that is
34 > obviously sub-optimal. This will be
35 > - # obvious if
36 > any of the non-asap selected_nodes
37 > - # is a leaf
38 > node when medium_soft deps are
39 > - # ignored.
40 > - if
41 > prefer_asap and asap_nodes and \
42 > -
43 > len(selected_nodes) > 1:
44 > - for
45 > node in selected_nodes.difference(
46 > -
47 > asap_nodes):
48 > -
49 > if not mygraph.child_nodes(node,
50 > -
51 > ignore_priority =
52 > -
53 > DepPriorityNormalRange.ignore_medium_soft):
54 > -
55 > selected_nodes = None
56 > -
57 > break
58 > - if
59 > selected_nodes:
60 > - if
61 > smallest_cycle is None or \
62 > -
63 > len(selected_nodes) < len(smallest_cycle):
64 > -
65 > smallest_cycle = selected_nodes
66 > + if
67 > smallest_cycle is None or \
68 > +
69 > len(selected_nodes) < len(smallest_cycle):
70 > +
71 > smallest_cycle = selected_nodes
72 > selected_nodes =
73 > smallest_cycle
74 > - if selected_nodes and debug:
75 > - writemsg("\nruntime
76 > cycle digraph (%s nodes):\n\n" %
77 > -
78 > (len(selected_nodes),), noiselevel=-1)
79 > + if selected_nodes is not
80 > None: cycle_digraph = mygraph.copy()
81 > cycle_digraph.difference_update([x
82 > for x in cycle_digraph if x not in selected_nodes])
83 > -
84 > cycle_digraph.debug_print()
85 > - writemsg("\n",
86 > noiselevel=-1) +
87 > + leaves =
88 > cycle_digraph.leaf_nodes()
89 > + if leaves:
90 > + # NOTE: This
91 > case should only be triggered when
92 > + #
93 > prefer_asap is True, since otherwise these
94 > + # leaves
95 > would have been selected to merge
96 > + # before
97 > this point. Since these "leaves" may
98 > + # actually
99 > have some low-priority dependencies
100 > + # that we
101 > have intentionally ignored, select
102 > + # only one
103 > node here, so that merge order
104 > + # accounts
105 > for as many dependencies as possible.
106 > +
107 > selected_nodes = [leaves[0]] +
108 > + if debug:
109 > +
110 > writemsg("\nruntime cycle digraph (%s nodes):\n\n" %
111 > +
112 > (len(selected_nodes),), noiselevel=-1)
113 > +
114 > cycle_digraph.debug_print()
115 > +
116 > writemsg("\n", noiselevel=-1) +
117 > + if leaves:
118 > +
119 > writemsg("runtime cycle leaf: %s\n\n" %
120 > +
121 > (selected_nodes[0],), noiselevel=-1)
122 > if prefer_asap and
123 > asap_nodes and not selected_nodes: # We failed to find any asap nodes
124 > to merge, so ignore diff --git
125
126 As usual, we are not resolver guru's, but the code changes look decent
127 enough :)
128
129 LGTM
130
131 --
132 Brian Dolbec <dolsen>

Replies