| 1 |
Was talking with a guy yesterday who mentioned he had 10 line patch that sped
|
| 2 |
up current portage a lot with regard to updating metadata. I asked him to
|
| 3 |
send it to me and here it is:
|
| 4 |
|
| 5 |
--- - 2005-10-29 18:49:15.156173000 +0900
|
| 6 |
+++ /usr/lib/portage/pym/portage_db_cpickle.py 2005-10-08 11:13:37.000000000
|
| 7 |
+0900
|
| 8 |
@@ -61,6 +61,9 @@
|
| 9 |
return False
|
| 10 |
|
| 11 |
def sync(self):
|
| 12 |
+ return
|
| 13 |
+
|
| 14 |
+ def realsync(self):
|
| 15 |
if self.modified:
|
| 16 |
try:
|
| 17 |
if os.path.exists(self.filename):
|
| 18 |
@@ -74,6 +77,6 @@
|
| 19 |
pass
|
| 20 |
|
| 21 |
def close(self):
|
| 22 |
- self.sync()
|
| 23 |
+ self.realsync()
|
| 24 |
self.db = None;
|
| 25 |
|
| 26 |
|
| 27 |
Obvious why it speeds it up. ;)
|
| 28 |
|
| 29 |
I remembered seeing sync_rate when glancing through the new cache stuff and
|
| 30 |
then had a look into mirror_cache(). Playing with trg_cache.sync(x), I got
|
| 31 |
the following numbers.
|
| 32 |
|
| 33 |
x total #1 total #2 total #3 median sys
|
| 34 |
1 13.651 13.451 13.727 2.712
|
| 35 |
10 13.413 13.412 13.645 2.538
|
| 36 |
100 13.605 13.498 13.405 2.700
|
| 37 |
1000 13.673 13.726 13.748 2.839
|
| 38 |
10000 14.541 14.054 13.447 2.743
|
| 39 |
100000 13.973 13.951 14.512 2.881
|
| 40 |
1000000 13.583 13.622 13.935 2.669
|
| 41 |
|
| 42 |
Command run was:
|
| 43 |
|
| 44 |
rm -rf /var/cache/edb/dep/*; time emerge -q metadata
|
| 45 |
|
| 46 |
So what does changing the sync_rate actually do? Ease seeks? Should I re-run
|
| 47 |
these tests with a reboot in between? (And what happened to the 4 seconds I
|
| 48 |
was getting with earlier patches? Bug fixes turn quantity into quality? :)
|
| 49 |
|
| 50 |
--
|
| 51 |
Jason Stubbs
|
| 52 |
|
| 53 |
--
|
| 54 |
gentoo-portage-dev@g.o mailing list |
Archives