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