On Fri, 07 Nov 2014 20:08:12 +0100 hasufell wrote: > On 11/07/2014 07:54 PM, Matthias Maier wrote: > >> 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). > > > > I think you didn't get the idea: it doesn't make much sense to compare > the speed if the correctness differs. > > Also, I don't understand these discussions. The time dependency > resolving takes is marginal compared to the whole update process, no > matter what PM you use.
Time required for user's attention differs from time required for CPU to work. During main update process portage just works for a few days (and then I have to deal with failed packages, but that's another story). As for dependency resolution during world update, this process is usually iterative: portage failes due to some unsatisfied USE flags, blocks, circular deps and so on. After resolving one of this problems emerge needs to be run one more time and so on. On old hardware iteration takes up to an hour (even with sqlite cache! 1 hour of CPU time), so a day or sometimes even two needed just to start actual build process! Now take into account that not always it is possible to spend all day just to start package's building, so world updates spans to weaks... With 10x times faster deps resolver it will be possible to handle all these issues in a few hours and let it contiue update on its own. Best regards, Andrew Savchenko
pgpzthrkOYUU1.pgp
Description: PGP signature
