| 1 |
On 01/10/2014 08:16 AM, heroxbd@g.o wrote: |
| 2 |
> Igor <lanthruster@×××××.com> writes: |
| 3 |
> |
| 4 |
>> The ebuilds have approximately the same time to install, the failure |
| 5 |
>> rate is about the same, emerge is getting slower. |
| 6 |
> |
| 7 |
> I am curious about the slowness of emerge. |
| 8 |
> |
| 9 |
> How about profile the portage and rewrite the time-crucial part in |
| 10 |
> C/C++, or ideally, borrowing the counterpart from paludis? How feasible |
| 11 |
> is that? |
| 12 |
|
| 13 |
Last I checked paludis wasn't faster - on average portage was a few |
| 14 |
percents faster. |
| 15 |
|
| 16 |
For python things you really want python or C instead of C++... |
| 17 |
|
| 18 |
So, what you wanted to ask was: |
| 19 |
"Which parts of pkgcore can be migrated into portage?" |
| 20 |
|
| 21 |
> I guess the dep-tree calculation is the slowest part. |
| 22 |
Yes, it's doing lots of silly dynamic things (backtracking), and portage |
| 23 |
codebase |
| 24 |
on average is not designed for speed. |
| 25 |
|
| 26 |
As a first step I would recommend profiling it and removing unneeded |
| 27 |
stuff (do less work!), rewriting parts in C is a lot of work and not |
| 28 |
needed for the first round of speedups. |
Archives