From: | heroxbd@g.o | ||
---|---|---|---|
To: | gentoo-dev@l.g.o | ||
Subject: | Re: [gentoo-dev] Portage QOS | ||
Date: | Fri, 10 Jan 2014 09:10:23 | ||
Message-Id: | 86a9f48aoi.fsf@moguhome00.in.awa.tohoku.ac.jp | ||
In Reply to: | Re: [gentoo-dev] Portage QOS by Tom Wijsman |
1 | Tom Wijsman <TomWij@g.o> writes: |
2 | |
3 | >> I am curious about the slowness of emerge. |
4 | > |
5 | > Try a --backtrack=0 approach, I no longer need to increase it. :) |
6 | |
7 | on a random box: |
8 | |
9 | time emerge --backtrack=0 -pe @world |
10 | [...] |
11 | real 0m30.016s |
12 | user 0m29.268s |
13 | sys 0m0.704s |
14 | |
15 | time emerge -pe @world |
16 | [...] |
17 | real 0m35.037s |
18 | user 0m30.824s |
19 | sys 0m1.136s |
20 | |
21 | not a big difference? |
22 | |
23 | >> How about profile the portage and rewrite the time-crucial part in |
24 | >> C/C++, or ideally, borrowing the counterpart from paludis? How |
25 | >> feasible is that? |
26 | > |
27 | > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0.png |
28 | > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0-hot.png |
29 | > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-3.3-backtrack-0.png |
30 | > |
31 | > (hot is the hotshot profiler, it internally checks on the line level |
32 | > instead; 3.3's profiler is obstructed by module loading, no idea why) |
33 | |
34 | Great! That's what I am looking for. |
Subject | Author |
---|---|
Re: [gentoo-dev] Portage QOS | Tom Wijsman <TomWij@g.o> |