| 1 |
On Thu, Oct 13, 2005 at 10:17:26AM +0200, Nagatoro wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
> >Curious about feedback from general usage, emerge -s, emerge -Dup |
| 4 |
> >world, etc. timing runs would be appreciated |
| 5 |
|
| 6 |
> portage 2.0.53_rc5 - 3.0-cache-backport-experimental-7 |
| 7 |
> |
| 8 |
> emerge -s portage: |
| 9 |
> |
| 10 |
> real 0m10.855s |
| 11 |
> user 0m2.610s |
| 12 |
> sys 0m0.537s |
| 13 |
> |
| 14 |
> emerge -Dup: |
| 15 |
> |
| 16 |
> real 0m40.443s |
| 17 |
> user 0m18.300s |
| 18 |
> sys 0m3.465s |
| 19 |
|
| 20 |
Don't spose you could attempt the tests above with the cache patches, |
| 21 |
plus the patch I've attached? It adds lastX caching back in, should |
| 22 |
reduce sys a _bit_, although personally I'm not expecting a helluva |
| 23 |
lot out of it. |
| 24 |
|
| 25 |
Part of the reason is that by it's nature, it only improves sequential |
| 26 |
calls for the same keys. emerge does it on occasion, but I'm not |
| 27 |
betting their would be a helluva lot of gain. repoman may benefit, |
| 28 |
since it's code is horrid though. |
| 29 |
|
| 30 |
Either way... locally, I'm getting pretty much no gain detectable in |
| 31 |
the usual testing noise, so curious if anyone else can see anything |
| 32 |
out of it. |
| 33 |
|
| 34 |
If it has a usable affect, it's going to show on systems with piss |
| 35 |
poor IO, and minimal kernel buffering. |
| 36 |
~harring |
Archives