On 31/01/2014 23:18, Andrew Savchenko wrote: > IMO the only way to improve this issue (without throwing good working > hardware in the window) is to rewrite dependency resolution code in > some highly optimized pure C library (probably with some asm code)
I very much doubt that will help. There's nothing unusual about portage's dep resolution - it's just a tree search. This is a well-understood problem and we've known how to DoItRite for 30 years or more. Python is already optimized to do this just fine, and it's bytecode, NOT classic interpreted. Rewriting it in C probably won't do much as C isn't a magic bullet. > and to use this library via some python binding from portage. But I > suppose algorithm itself should be reviewed first. ^this is where the speedups will lie 4 minutes on this here i7 monster and 40 on your Atom is ridiculous considering the problem that is being solved. Portage is probably searching and re-searching dead paths in the tree or something equally silly. The algorithm should be analysed and dead paths optimized away. Not a language problem. -- Alan McKinnon alan.mckin...@gmail.com
