Archives
Archives
| From: | Tom Wijsman <TomWij@g.o> | ||
|---|---|---|---|
| To: | heroxbd@g.o | ||
| Cc: | gentoo-dev@l.g.o | ||
| Subject: | Re: [gentoo-dev] Portage QOS | ||
| Date: | Fri, 10 Jan 2014 01:03:22 | ||
| Message-Id: | 20140110020218.0f6244d5@TOMWIJ-GENTOO | ||
| In Reply to: | Re: [gentoo-dev] Portage QOS by heroxbd@gentoo.org | ||
| 1 | On Fri, 10 Jan 2014 09:16:47 +0900 |
| 2 | heroxbd@g.o wrote: |
| 3 | |
| 4 | > Igor <lanthruster@×××××.com> writes: |
| 5 | > |
| 6 | > > The ebuilds have approximately the same time to install, the failure |
| 7 | > > rate is about the same, emerge is getting slower. |
| 8 | > |
| 9 | > I am curious about the slowness of emerge. |
| 10 | |
| 11 | Try a --backtrack=0 approach, I no longer need to increase it. :) |
| 12 | |
| 13 | > How about profile the portage and rewrite the time-crucial part in |
| 14 | > C/C++, or ideally, borrowing the counterpart from paludis? How |
| 15 | > feasible is that? |
| 16 | |
| 17 | http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0.png |
| 18 | http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0-hot.png |
| 19 | http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-3.3-backtrack-0.png |
| 20 | |
| 21 | (hot is the hotshot profiler, it internally checks on the line level |
| 22 | instead; 3.3's profiler is obstructed by module loading, no idea why) |
| 23 | |
| 24 | > I guess the dep-tree calculation is the slowest part. |
| 25 | |
| 26 | Affirmative. |
| 27 | |
| 28 | -- |
| 29 | With kind regards, |
| 30 | |
| 31 | Tom Wijsman (TomWij) |
| 32 | Gentoo Developer |
| 33 | |
| 34 | E-mail address : TomWij@g.o |
| 35 | GPG Public Key : 6D34E57D |
| 36 | GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
| File name | MIME type |
|---|---|
| signature.asc | application/pgp-signature |
| Subject | Author |
|---|---|
| Re: [gentoo-dev] Portage QOS | heroxbd@g.o |
