On 06/16/2013 11:23 AM, Tom Wijsman wrote: > Ignoring that call graph, you could look at what has recently been > introduced to increase the amount of time needed to calculate the > dependency graph; you don't have to look far. > > http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/ > > While I don't want point out the contents of that blog post, the title > is relevant; implementing features like subslots on an algorithm that > was not written with subslots in mind introduces a lot of inefficiency.
It's actually not bad, since all of the subslot rebuilds are triggered in a single backtracking run. Anyway, I welcome having people work on competing package managers, trying to do all of this stuff more efficiently. :-) > And it's not just subslots, newer features keep getting added to the > dependency graph calculation and it gets slower and slower over time. > It feels like revdep-rebuild moved into the dependency calculation! I guess the main things that make it slower than it has been historically would be things like --autounmask, --backtrack, --complete-graph-if-new-use and --complete-graph-if-new-ver. Note that you can use EMERGE_DEFAULT_OPTS to disable these things if you would prefer to live without them. You might use something like --backtrack=2 if you want it to bail out early for all but the simplest backtracking cases. Use --ignore-built-slot-operator-deps=y if you want to disable all rebuilds involving subslots and slot-operators. -- Thanks, Zac
