1 |
Hello, |
2 |
|
3 |
On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote: |
4 |
> On 11/17/2014 09:47 PM, Andrew Savchenko wrote: |
5 |
> > I use 2.2.14 on both hosts (and usually latest ~x86 portage is |
6 |
> > there). I thought that running fixpackages should be enough to run |
7 |
> > emerge with --dynamic-deps=n. |
8 |
> |
9 |
> It depends on how badly the installed deps have diverged from the |
10 |
> corresponding ebuilds in the tree. |
11 |
|
12 |
I tried fixpackages. It fixed some problems and looks like |
13 |
dependencies resolution became faster. But not all problems are |
14 |
fixed and I can't use --dynamic-deps n on both systems for now; |
15 |
and emerge @changed-deps fails due to numerous conflicts, blocks, |
16 |
unsatisfied deps (this is not surprising, since it doesn't try to |
17 |
update all packages in tree). |
18 |
|
19 |
By the way, is there any way to unroll conflict lists in portage |
20 |
output? I mean if I have following: |
21 |
|
22 |
(dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by |
23 |
>=dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed) |
24 |
^^^^^^^^^ |
25 |
(and 68 more with the same problem) |
26 |
|
27 |
How can I see all list of these 68 packages? Sometimes this feature is |
28 |
really desired, e.g. if I don't want to update all @world but need to |
29 |
apply GLSA fix which leads to similar conflicts. I can't find any |
30 |
switch in emerge manual. |
31 |
|
32 |
> > When I'll manage to run emerge -DNupv @world without errors, I'll |
33 |
> > send you stats for both runs with and without dynamic deps. |
34 |
> |
35 |
> Great, hopefully that will reveal some more good things to optimize. |
36 |
> |
37 |
> > By the way, do you need pstats files (e.g. for some extra data) or |
38 |
> > pdf graphs are sufficient? |
39 |
> |
40 |
> The pdf graphs are typically enough for me, since they highlight the hot |
41 |
> spots really well. I did not even bother with your pstats files. |
42 |
|
43 |
OK. I managed to run emerge -DNupv @world on desktop without |
44 |
conflicts. What was done: |
45 |
1) fixpacgkages run |
46 |
2) portage is updated to use your patch from bug 529660 |
47 |
|
48 |
At this point performance boost was really great: from ~35 |
49 |
minutes to ~19-20 minutes. |
50 |
|
51 |
Afterward I tried emerge -DNupv @world with different python |
52 |
versions: |
53 |
(2.7) (~)2.7.8 |
54 |
(3.3) 3.3.5-r1 |
55 |
(3.4) (~)3.4.2 |
56 |
|
57 |
Results are interesting (confidence level for error is 0.95, time |
58 |
real value was used for calculations): |
59 |
3.3 is 3% ± 5% faster than 2.7 |
60 |
3.4 is 20% ± 5% faster than 3.3 |
61 |
And with python:3.4 and steps above it takes now 15.5 minutes |
62 |
instead of 35. Nice result :) |
63 |
|
64 |
So there is no evidence that portage on 3.3 is faster than on 2.7, |
65 |
but 3.4 is faster than 3.3 with very good confidence. Of course |
66 |
this data is biased by -m cProfile overhead, but bias should |
67 |
similar for each version. Just checked time to run command for |
68 |
python:3.4 without profiling: it takes 11.5 minutes! |
69 |
|
70 |
You may find generated pdf graphs together with system information |
71 |
for each host here: |
72 |
ftp://brunestud.info/gentoo/portage-v2.tar.xz |
73 |
|
74 |
As for hitomi box, it is both slower and have much older packages, |
75 |
so I'm still struggling to fix conflicts and other issues. Results |
76 |
will be available later. |
77 |
|
78 |
P.S. Note for those who would like to use gpro2dot: it should be |
79 |
run with the same python interpreter active as was used during |
80 |
pstats data collection, otherwise it will fail to process data. |
81 |
I spent some time while figuring this out. |
82 |
|
83 |
Best regards, |
84 |
Andrew Savchenko |