| 1 |
On Mon, Jan 13, 2014 at 7:38 AM, Luis Ressel <aranea@×××××.de> wrote: |
| 2 |
|
| 3 |
> On Mon, 13 Jan 2014 15:58:13 +0100 |
| 4 |
> Tom Wijsman <TomWij@g.o> wrote: |
| 5 |
> |
| 6 |
> > On Mon, 13 Jan 2014 10:31:56 +0100 |
| 7 |
> > Fabio Erculiani <lxnay@g.o> wrote: |
| 8 |
> > |
| 9 |
> > > Portage can still take *minutes* to calculate the merge queue of a |
| 10 |
> > > pkg with all its deps satisfied. |
| 11 |
> > |
| 12 |
> > Half a minute if you disable backtracking which you don't need. :) |
| 13 |
> |
| 14 |
> Which sadly also means that some updates get skipped silently. (Those |
| 15 |
> which would trigger rebuilds of other packages because of sub-slot |
| 16 |
> deps, had that case yesterday). |
| 17 |
> |
| 18 |
> > > Ironically, launching the same emerge command twice, will take more |
| 19 |
> > > or less the same time. |
| 20 |
> > |
| 21 |
> > Determinism results in more or less the same time, that's correct; |
| 22 |
> > proper benchmarks would show you a similar result. |
| 23 |
> |
| 24 |
> I guess he means that the (according to the file sizes) extensive |
| 25 |
> caching doesn't seem to be of much use. |
| 26 |
> |
| 27 |
|
| 28 |
The caching may not be of use, depending on your configuration. (For |
| 29 |
example, if you use a gentoo-x86 checkout as your main repo, you will |
| 30 |
probably want to run generate cache entries whenever you cvs up.) It is |
| 31 |
there to cache ebuild metadata, because if your depgraph has a few thousand |
| 32 |
nodes, having to spawn bash to generate the metadata for every node is very |
| 33 |
expensive. That being said, for most users that use rsync, the metadata is |
| 34 |
pre-generated. As long as they are not changing the cache indicators (not |
| 35 |
sure if this is mtime or md5sum these days) they should be seeing a benefit. |
| 36 |
|
| 37 |
This is not meant to imply that portage is always fast; there are plenty of |
| 38 |
other modules (such as the aforementioned backtracking) that can take a |
| 39 |
long time to find solutions. That is partially why you see Tomwij turning |
| 40 |
off that feature. It is helpful for users cause it can automatically find |
| 41 |
solutions for users that are otherwise unsolvable (and thus avoids the user |
| 42 |
having to find a solution to the depgraph manually.) |
| 43 |
|
| 44 |
-A |
| 45 |
|
| 46 |
|
| 47 |
> |
| 48 |
> -- |
| 49 |
> Luis Ressel <aranea@×××××.de> |
| 50 |
> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD |
| 51 |
> |
Archives