Alex Schuster wrote:
Dale writes:

Alex Schuster wrote:
Dale writes:
But if you emerge something and it has to be fetched first, is that
counted in the time genlop shows or not?  That is the question.  I
don't think it is counted but I'm not sure.
That's what I thought, too, but then I simply tried to be sure.
Download time _is_ counted.
Now we know.  If I was on dial-up again, I could sure test that theory.
3KBs/sec would certainly make a difference.  :-(  Pardon me if I refuse
to go back tho.  I like youtube to much.
It's easier than that, I simply emerged vanilla-sources-3.0 after deleting
the tarball. I did not use my digital wrist-watch which I could have done,
instead I looked into emerge.log. The long numbers to the left are seconds
since 1970, the difference is what genlop uses. The only question was
whether it uses the line 'emerge (x of y) category/package-version to /' or
'(x of y) Compiling/Packaging ...' to determine the start time.


Smarty pants.  :-P   LOL

I set mine to fetch in the
background so most of the time the fetch is done after a couple
packages gets compiled.
What about parallel emerges? I guess genlop will not take this into
account.
I would think not.  As long as the tarball is downloaded before emerge
gets to it to compile.  I doubt it would even know how long it took to
download either.
I wasn't talking about the download time here, but about the total time. If
I emerge two independent packages A and B, which take one hour each to
build, what does genlop say if I use emerge -j and they build in parallel?
This would take about two hours for each. And indeed, that's what genlop
says. So genlop -t is inaccurate when you are emerging with the -j option.

        Wonko


Yea, when you have multiple compiles running at the same time, genlop is off from then on. It is the only thing I don't like about that option. Doing a genlop -t <package name> is no longer accurate either. I do use that sometimes too.

Dale

:-)  :-)

Reply via email to