| 1 |
On Thu, Oct 13, 2005 at 01:05:40PM +0200, Nagatoro wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
> Hmm, when trying to update the cache (emerge --metadata) I get this: |
| 4 |
> --- |
| 5 |
> >>> Updating Portage cache: |
| 6 |
> Traceback (most recent call last): |
| 7 |
> File "/usr/bin/emerge", line 2734, in ? |
| 8 |
> cache.util.mirror_cache(source, cm, pdb.auxdb[porttree_root], |
| 9 |
> eclass_cache=ec, verbose_instance=noise_maker) |
| 10 |
> File "/usr/lib/portage/pym/cache/util.py", line 22, in mirror_cache |
| 11 |
> if not trg_cache.autocommits: |
| 12 |
> AttributeError: CachingDict instance has no attribute 'autocommits' |
| 13 |
> --- |
| 14 |
> but if I remove the lastX patch it workes. |
| 15 |
|
| 16 |
*cough*, that's cause lastX is a dirty hack externally, rather then |
| 17 |
implemented w/in the cache backend for testing. That and I forgot to |
| 18 |
define that method. :) |
| 19 |
|
| 20 |
Basically it wraps the cache repo obj- if it proved to make a decent |
| 21 |
difference, would go through and integrate it better. |
| 22 |
|
| 23 |
> portage 2.0.53_rc5 - 3.0-cache-backport-experimental-7 + lastx |
| 24 |
> emerge -s portage: |
| 25 |
> |
| 26 |
> real 0m12.891s |
| 27 |
> user 0m3.030s |
| 28 |
> sys 0m0.576s |
| 29 |
> |
| 30 |
> After running this with and without the lastx patch I seem to get |
| 31 |
> slighly longer times (real and user) with it (~0.5s real and user) and |
| 32 |
> slightly shorter sys times (~0.2s). |
| 33 |
> |
| 34 |
> emerge -Dup world: |
| 35 |
> |
| 36 |
> real 0m38.113s |
| 37 |
> user 0m18.186s |
| 38 |
> sys 0m2.916s |
| 39 |
> |
| 40 |
> And here I seem to get slightly shorter real and sys times but |
| 41 |
> slightly longer user times (~0.5s real and user, ~0.2s sys). |
| 42 |
> |
| 43 |
> But the times varies way to much to "prove" this. |
| 44 |
|
| 45 |
Pretty much is exactly what I've seen |
| 46 |
Haven't gotten any conclussive stats out of it. |
| 47 |
fex, testing via- |
| 48 |
|
| 49 |
cd /usr/portage ; for x in 1 2; do time repoman scan &> /dev/null ; |
| 50 |
done ; cd /usr/lib/portage/pym/; patch -p2 -i ~/lastx.patch ; cd |
| 51 |
/usr/portage ; for x in 1 2; do time repoman scan &> /dev/null ; done |
| 52 |
; cd /usr/lib/portage/pym/; patch -p2 -i ~/lastx.patch -R |
| 53 |
|
| 54 |
real 53m30.754s |
| 55 |
user 34m25.549s |
| 56 |
sys 6m11.663s |
| 57 |
|
| 58 |
real 49m16.141s |
| 59 |
user 32m48.835s |
| 60 |
sys 5m52.882s |
| 61 |
|
| 62 |
patching file cache/mappings.py |
| 63 |
patching file portage.py |
| 64 |
|
| 65 |
real 51m4.228s |
| 66 |
user 34m24.005s |
| 67 |
sys 6m4.447s |
| 68 |
|
| 69 |
real 51m16.202s |
| 70 |
user 34m21.253s |
| 71 |
sys 6m1.315s |
| 72 |
patching file cache/mappings.py |
| 73 |
patching file portage.py |
| 74 |
|
| 75 |
About the only thing I've seen with the patch is less variation in the |
| 76 |
results, although never hitting the best runs unpatched does. |
| 77 |
|
| 78 |
Either way, thanks for testing it :) |
| 79 |
~harring |
Archives