1 |
On Saturday 17 January 2015 13:12:56 Zac Medico wrote: |
2 |
> On 01/17/2015 03:35 AM, Patrick Lauer wrote: |
3 |
> > * Portage is too slow |
4 |
> > |
5 |
> > On 'small' hardware emerge -upNDv @world can take enough time |
6 |
> > to make updates prohibitive - on an 800Mhz machine it took me |
7 |
> > about 3 days to figure out a solution to some silly blockers due to |
8 |
> > the |
9 |
> > very slow change test cycle |
10 |
> > Fix: Do some profiling and un-refactoring to remove useless code |
11 |
> > Fix: Set up a reference system (CI) to catch future regressions |
12 |
> |
13 |
> I'm certainly in favor of improving portage performance. However, for |
14 |
> "small" hardware (which includes many ARM and MIPS systems), we really |
15 |
> need to focus on binary package support. Note that dependency resolution |
16 |
> for installing binary packages tends to be much simpler than for |
17 |
> building ebuilds from source, and this translates into much shorter |
18 |
> dependency resolution time. |
19 |
> |
20 |
That's an orthogonal problem. And that's coming from someone who extensively |
21 |
uses binpkgs already ... |
22 |
|
23 |
The problem with (dependency resolution) performance is that in some |
24 |
scenarios, even on fast machines, it takes "too long" - especially if there's |
25 |
some silly useflag mismatch and two packages that have ~arch keywords, and now |
26 |
you need 12 attempts to figure out a solution that works for you ... |
27 |
At 30 seconds for each resolution cycle that's 6 minutes waiting for portage. |
28 |
|
29 |
If it were faster it'd almost be interactive ... |
30 |
|
31 |
Also - just for comparison: |
32 |
On my currently fastest box "emerge -ep @world" takes about 3 seconds since |
33 |
there's almost no packages installed. |
34 |
On my currently slowest box same takes about 15 minutes, because (1) lots of |
35 |
packages installed and (2) slow CPU and (3) brutally slow IO |
36 |
|
37 |
Binpkgs only help so much - if any dependencies change I need to sync the |
38 |
configuration between client and server, and to see if it resolves I need to do |
39 |
a dryrun on the client (or be very certain that the configuration really |
40 |
matches) - or risk that it's going to fail because of mismatches. |
41 |
|
42 |
|
43 |
I haven't quite figured out why portage needs such humongous amounts of memory |
44 |
(>300MB ?!) and why it needs to spend a minute to figure out how to install a |
45 |
simple almost-no-dependencies tool like htop or iotop. There's some obvious |
46 |
badness, and just saying "well let's use binpkgs" won't fix it (and, well, on |
47 |
the binpkg server if you have 3k packages installed you get the same |
48 |
performance issues, so ignoring the issue is kinda not a good idea) |
49 |
|
50 |
There's been some good progress, I remember you reducing memory usage already |
51 |
(>500MB -> 350MB or so for merging kernel sources) and there's some speedups |
52 |
from the last round of performance work. Still I think we can do a lot better |
53 |
:) |
54 |
|
55 |
Thanks for your efforts, |
56 |
|
57 |
Patrick |