| 1 |
On Sun, Jan 26, 2014 at 6:35 AM, Nikos Chantziaras <realnc@×××××.com> wrote: |
| 2 |
> Anyone else noticed this yet? Some portage update seems to have made "emerge |
| 3 |
> -uDN @world" perform about 10 times slower than before. It used to take |
| 4 |
> seconds, now it takes about 4 minutes only to tell me that there's nothing |
| 5 |
> to update. And it does that every time, even directly in succession and with |
| 6 |
> the caches warm. |
| 7 |
> |
| 8 |
> Is it just me? |
| 9 |
|
| 10 |
Usually this occurs when you have done something that causes portage |
| 11 |
to stop using the metadata that rolls in via rsync. The classic |
| 12 |
example of something that will cause this is setting some |
| 13 |
eclass-overrides in /etc/portage/repos.conf. |
| 14 |
|
| 15 |
As of yesterday, portage still performed tolerably on a relatively |
| 16 |
vanilla base system. |
| 17 |
|
| 18 |
That stated, you're not hallucinating. Portage is slow as tar. I |
| 19 |
suspect it's getting slower at least partially as a result of the |
| 20 |
recent explosion of multilib-build-based ebuilds for multimedia and |
| 21 |
x11 library ebuilds, and perhaps also due to those nasty |
| 22 |
emul-linux-x86 blockers (a problem that will eventually be resolved, |
| 23 |
Larry-The-Cow-God-willing, within a year or three) that are placing |
| 24 |
higher and higher demands on portage's depsolving engine, as time |
| 25 |
passes. |
| 26 |
|
| 27 |
Having lots and lots of packages installed is a huge factor here. |
| 28 |
This may be because, by default, portage uses installed packages to |
| 29 |
calculate dependencies, resulting in a need to re-cache lots of |
| 30 |
stuff... I'm a bit fuzzy on exactly what criteria are used to |
| 31 |
determine when this happens, tbh.. that's something I've been meaning |
| 32 |
to look into. |
| 33 |
|
| 34 |
Adding something like: |
| 35 |
|
| 36 |
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --backtrack=5" |
| 37 |
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph=n" |
| 38 |
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-use=n" |
| 39 |
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-ver=n" |
| 40 |
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --with-bdeps=n" |
| 41 |
|
| 42 |
to you /etc/portage/make.conf may help, as may running emerge |
| 43 |
--metadata and/or egencache on your repos. after syncing... but... |
| 44 |
these are no panacea. |
| 45 |
|
| 46 |
Sometimes emerge -O is the only way to get some things done in any |
| 47 |
reasonable time-frame. |
| 48 |
|
| 49 |
It would help if there were some decent way to get some statistics |
| 50 |
about where portage is spending all its time (especially, I suspect, |
| 51 |
within the bash code, but the python level would also be interesting |
| 52 |
to analyse). Anyone know of a good way of doing that? |
| 53 |
|
| 54 |
-gmt |
Archives