Why has portage become so slow

[percy_vere_uk]

Hi

I have noticed recently that 'emerge -pv --update --deep --newuse world' takes several times longer than it used to. This now takes around 5 minutes, a couple of months ago this was less than a

minute.

Emerging a single package also takes several times longer than before. I have two gentoo systems on the same laptop and since bringing the second one up to date it is now acting the same.

Any ideas on the cause of this. One of the updates perhaps!

percy

[yellowhat]

That's the same impression I get.
I am runnimg: sys-apps/portage-2.2.7

[PaulBredbury]

Just idle speculation: try byte-compiling, e.g.:

[dol-sen]

The reason is the new EAPI 5 subslot capabilities as well as a few other features that make finding a working solution to the upgrade/merge path have to do a lot more work. With the subslot capability allowing for automatic re-building of pkgs, it has to do a lot more reverse dep checks to ensure it doesn't break other installed pkgs, plus it has to check/find solutions to upgrade/ignore other pkgs that may bring in slot conflicts.

Essentially, portage is doing more so you don't have to figure out conflicts, rebuild the stuff on your own.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

[xaviermiller]

Bug #468486
Bug #484788
Bug #431484

For me, that delay is unacceptable, I cannot use emerge as I did before. Too slow.
_________________
Kind regards,
Xavier Miller

[Aiken]

Had a look at those bug reports and saw someone with 11 minutes. My worst so far is 7 minutes with 4 - 5 common. With 12 gentoo images to look after that time adds up.

Core2duo 3.16GHz, 4G ram, wd 160G hd.

[xaviermiller]

And compared to paludis ?
_________________
Kind regards,
Xavier Miller

[percy_vere_uk]

dol-sen has explained this slow down "essentially, portage is doing more so you don't have to figure out conflicts, rebuild the stuff on your own."

So it appears to be beyond my control, I have to say the delay is annoying though!

percy

[xaviermiller]

For me, it's not solved.
_________________
Kind regards,
Xavier Miller

[mv]

A certain factor of speed can still be obtained by using squashfs for the portage tree and for /var/db/pkg (e.g. sys-fs/squashmount from the mv overlay, see here). On my system the speed gain is still considerable, but your milage may vary. Roughly speaking, the more memoy your machine has and the faster it is anyway, the less will be the gain.

[xaviermiller]

I use squashfs, the lost time is not in i/o but in python code.
_________________
Kind regards,
Xavier Miller

[mv]

[xaviermiller]

I don't want to tune portage. It worked fine until last months, it needs to be profiled / fine tuned.
_________________
Kind regards,
Xavier Miller

[percy_vere_uk]

XavierMiller said "For me, it's not solved."

OK I have removed the solved. Lets hope it is solved at some point.

percy

[mv]

[xaviermiller]

I am a user, not a NP-Case

My world is simplier this year than years ago, I see Portage has become too bloated and need some fitness to be useable again. It's a "normal" milestone, like other projects, some optimizations need to be done after too much evolutions in all directions.

If portage cannot be optimized, I will try other package management systems... and so would be on the slope to exit.
_________________
Kind regards,
Xavier Miller

[GFCCAE6xF]

Is there anything the seemingly very people affected by this have in common?

Personally, I haven't noticed any slow-downs during the past year or so and doing Aiken's basic benchmark/test myself I get a time of 36 seconds and 11 seconds on following tries without the drop cache play.

[xaviermiller]

I have 2 machines with almost the same world. The ~amd64 is OK and not slow, but the ~x86 is really slow. And compared to CPU frequencies, the ratio is not related only to frequencies differences.
_________________
Kind regards,
Xavier Miller

[TomWij]

To get an idea what's going on, here is a slightly more verbose overview:

0:00: Calculating dependencies
0:07: Adding root packages
0:17: Processing dependencies
1:06: Adding root packages
1:08: Processing dependencies
1:43: Adding root packages
1:46: Processing dependencies
2:45: Checking for slot conflicts
2:45: Trying to accept blocker conflicts
2:45: Resolving slot conflicts for complete graph
2:45: Processing slot conflicts
2:45: Triggering slot operator reinstalls
3:18: Validating blockers
3:21: Checking for blocker conflicts
3:21: Checking for rebuild triggers
3:21: Checking if restart is needed
3:21: Checking if we have to prune rebuilds
3:21: Checking if restart is needed
3:21: Checking for parameters that change behavior
3:21: Checking for changes that are needed
3:21: Done resolving! ... done

(This output can be obtained with something like https://gist.github.com/TomWij/d25d1c8f4cf2b2122b0d)

As you can see, 2 minutes and 45 seconds is spent on building the Portage tree and 33 seconds on the slot conflicts.

There are options (--ignore-built-slot-operator-deps=y and --rebuild-if-new-slot=n) that can be played with to get rid of that 33 seconds; but if you do so, you are moving that time to other places where you might possibly have to spend a lot more time on it. I don't think it is really worth disabling it...

As for the 2 minutes and 45 seconds, that depends a lot on your Portage tree; while one way would be dealing with the code (which is a hard thing to do) you can also do it the other way:

• Make sure you only have the overlays you actually need; if possible, just pull ebuilds from overlays to your own overlay. Having a lot of overlays can slow things down a lot.
  
• Make sure you clean out /var/lib/portage/world once in a while to get rid of packages you don't actually need.
  
• Whenever you merge something think about why the dependencies are pulled in (--tree --unordered-display), do you actually need them? Disable the USE flags if you don't.
  
• Find packages that don't have a lot of dependencies for what they need to do, light-weight software can have its benefits.
  

All these will make the dependency tree smaller, which means it would be done faster.

Some ideas for dependency tree resolution involve even more caching (eg. for reducing the USE flags), making it parallel (but Python global interpreter lock sits in the way) or just plain rewriting it with an alternative backtracking algorithm.

Talking about backtracking, you might want to lower the value by default such that it doesn't consider too much; then when you get problems you can increase it temporarily and run again.

And for those interested, here is a call tree (http://i.imgur.com/A93CdNR.png) from a while ago and another call tree (http://i.imgur.com/UbxEUB2.png) that I captured last week. In the second one you see it run again (2x) to resolve some blockers or conflicts. There are multiple ways you can interpret what's heavy; but since I can't blindly trust that, it's why I'm looking at it from a top down approach (making it a bit more verbose with each try) but haven't found anything noteworthy to fix yet. I'm mostly looking at things that are done multiple time that could just be done a single time. (eg. A list that's not made unique; therefore having multiple entries, and processing the same entry twice is unnecessary)

[xaviermiller]

TL;DR As I stated, I see me in that case as a user, not a developer. I don't want to debug Python, but to have a working and fast PMS.

Can't Portage be KISSer ?
_________________
Kind regards,
Xavier Miller

[xaviermiller]

OK, I will elaborate : I follow the gentoo-dev mailing list, and I see a lot of people having nice ideas, and proposing new cool features or technical/technological solutions for special cases on dependencies/conflicts automatic solutions.

Indeed, there are really really cool features and Portage is those last months become really clever.

But we are at some point the software has more intelligence than the user. And it costs a lot of processing to run those cool algorithms.

For me, this is too much, or too much for an interpreted language.

As developer, I always prefer KISS solutions over "user friendly" pathes that sometimes don't help the user but don't help him/her to learn, and hide everything in a complicated stuff.

So, what is the cost of the resulting system? In some cases, maybe nothing. But in other cases, its too CPU expensive. And nobody can help me to help developers to point where the problem is (except theoretical stuff about algorithm complexity or non-default fine-tune parameters to check).

I have only 1 overlay (pro-audio), and a lot of USE flags because I don't want to be bloated by *kit/systemd/non-KISS/anti-UNIX pushed dependancies.

After 10 years of a simple and efficient portage, I am lost in a bloated PMS, with a lot of cryptical concepts that are not well explained to existing users (I don't follow the User Guide each month to see the difference). All I want to do is sync / update / install stuff, not install 3rd-party software to compute dependencies more efficiently; eix is my favorite tool, but a proof that portage is bloated. revdep-rebuild was useful, I could understand I need to use it again.

It's a pity that the idea of paludis was not integrated/studied but generated a fork.

Please, try to cut down portage and optimize it. This would be a benefit for everybody.

KISS. No more.
_________________
Kind regards,
Xavier Miller

[TomWij]

It is not so much about Portage becoming more complex alone; given that half minute added to three minutes that isn't really that much, and it spares out much more time than that half minute.

It's rather about the size and complexity of the Portage tree growing (http://i.imgur.com/mA6rMnY.png from http://tinyurl.com/gegraphs); as time goes by new packages come in, existing packages use new dependencies, programs grow more features (= often more dependencies covered under USE flags), more blockers come to live, more alternatives in virtuals and the list goes on...

Back in the middle ages post could be handled by one or two persons sitting at the post office, nowadays, our cities and connections are so crowded that automatic sorting machines and what not are necessary to keep up; so, that being said, Portage does a very good job at dealing with the complexity it is provided with. If there's one place that a gain could be found, it is in the complexity that we are building; and not necessarily in the package manager.

Although if there is a way to deal with the package manager instead of the Portage tree; then yes, it would be handy to be able to do it there. But there becomes a point you simply cannot optimize in big steps anymore...

(Word aside; I am not a Portage developer, despite a single commit)

[TomWij]

[modnaruved]

I dont update today and not saw any delays.


Just thinking in dream: maybe use erlang for package manager? but its more dependencies and not wide own package system and libs, but it can utilize all CPU-related resources for speed.... also git DCVS will help to fast sync

[Aiken]