| 1 |
On 01/11/2014 02:11 AM, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 10 Jan 2014 08:31:21 +0800 |
| 3 |
> Patrick Lauer <patrick@g.o> wrote: |
| 4 |
>> On 01/10/2014 08:16 AM, heroxbd@g.o wrote: |
| 5 |
>>> Igor <lanthruster@×××××.com> writes: |
| 6 |
>>> |
| 7 |
>>>> The ebuilds have approximately the same time to install, the |
| 8 |
>>>> failure rate is about the same, emerge is getting slower. |
| 9 |
>>> |
| 10 |
>>> I am curious about the slowness of emerge. |
| 11 |
>>> |
| 12 |
>>> How about profile the portage and rewrite the time-crucial part in |
| 13 |
>>> C/C++, or ideally, borrowing the counterpart from paludis? How |
| 14 |
>>> feasible is that? |
| 15 |
>> |
| 16 |
>> Last I checked paludis wasn't faster - on average portage was a few |
| 17 |
>> percents faster. |
| 18 |
> |
| 19 |
> Your benchmark was comparing uncached behaviour, where bash is the slow |
| 20 |
> part and which users don't see. |
| 21 |
Wrong - even the cached cases was showing the same timing proportions. |
| 22 |
|
| 23 |
And users see the uncached case whenever they use an overlay. |
| 24 |
|
| 25 |
> You were also not comparing like with |
| 26 |
> like -- any benchmarks of this nature should be taken with a heavy |
| 27 |
> pinch of salt, since Portage with everything turned on does less |
| 28 |
> validation that Paludis does with everything turned off... |
| 29 |
> |
| 30 |
Not my problem, bad code is bad. |
Archives