Am 07. Nov 2014, 19:30 schrieb Ciaran McCreesh <ciaran.mccre...@googlemail.com>:

> On Fri, 07 Nov 2014 19:11:04 +0100
> Jauhien Piatlicki <jauh...@gentoo.org> wrote:
>> Then the same question for you: where can one read about the algorithm
>> Paludis uses?
>
> It's basically a two stage process: simple constraint solving using
> value ordering heuristics to enforce "don't do unnecessary work", then
> ordering (which is not quite a graph process, and which is not as
> simple as a topological sort, because the tree is full of circular
> dependencies).
>
> But the interesting question isn't "what's the algorithm?", it's
> "what's the model?". That's where the complexity lies: figuring out how
> to turn *DEPEND specifications into constraints is an utter pain, and
> it isn't clean or easily understandable. The primary reason is ||
> dependencies: developers like to write not-really-correct and utterly
> unobvious dependency strings rather than asking for new syntax so they
> can just say what they mean...


Currently, for portage just to decide that nothing has to be done on my
machine takes around 1 minute.

What is in your opinion the main reason for this? And how can we knock
this down to reasonable speed?

 - Is our dependency model that more complex than the problem resolvers
   of other package managers for other distributions solve?

 - Is it the algorithm that is implemented for the dependency model?

 - Is it its implementation?


>> And, again, I have herd (did not try myself) that Paludis is as slow
>> as Portage.
>
> Well, you're not comparing like with like. Paludis with "everything
> turned off" does more than Portage with "everything turned on". If all
> you're looking for is the wrong answer as fast as possible, there are
> easier ways of getting it...

The last time I compared the resolver speed of portage and paludis both
needed almost the same time.

Do you have a speed comparison with a similar feature set of both? (Or,
alternatively, the speedup one gains by tuning paludis to be as fast as
possible).

Best,
Matthias

Reply via email to