Talk:Portupgrade

Revision as of 17:55, 10 July 2005

note on the rollback: I strongly prefer showing a pipe to grep rather than the -l argument because they both accomplish the same thing, but piping to grep is a universal tool than can be used with any command or process. It's a good habit to learn using tools and skills that are universally applicable as opposed to stuff that's only applicable to one particular task, unless there is some marked advantage to using the more proprietary method of doing things.

If you know of some particularly good reason to use the -l argument instead of piping to grep, by all means let me know here. --Jimbo 19:23, 9 Jul 2005 (EDT)

The goal is just avoiding to use two processes when only one is needed... More, I tried this :

Script started on Sun Jul 10 11:35:19 2005
# time portversion -l '<' > /dev/null 
portversion 1.90s user 0.68s system 86% cpu 3.001 total
# time portversion | grep '<' > /dev/null
portversion  2.68s user 0.88s system 69% cpu 5.102 total
grep '<' > /dev/null  0.00s user 0.00s system 0% cpu 5.100 total
Script done on Sun Jul 10 11:36:23 2005

I do not know how it work internaly, but I gess that the "-l" argument changes the search algorithme.

But I agree with your point of view... grep has to be known by the users ! The "-l" flag may sometimes be preferable, for a low system for example...

Yah, if I was scripting repeated operations, by all means I'd use the more efficient way. But in general I think the modularity of *nix is actually by far the best thing about it, and I try to do things as modular as possible if there isn't a compelling reason to do otherwise. Even in my own just day-to-day stuff; sure I already know about grep, but still actually using it for everything keeps me in the habit of using it and that's more useful to me than being in the habit of using something that only applies to portversion, y'know? =)

Btw, the difference in efficiency isn't anywhere near as compelling on my systems:

ph34r# /usr/bin/time -h portversion -l '<' > /dev/null
        0.88s real              0.70s user              0.18s sys
ph34r# /usr/bin/time -h portversion | grep '<' > /dev/null
        0.89s real              0.68s user              0.21s sys

or

blackbox# /usr/bin/time -h portversion -l '<' > /dev/null
        1.03s real              0.83s user              0.18s sys
blackbox# /usr/bin/time -h portversion | grep '<' > /dev/null
        1.04s real              0.83s user              0.19s sys

On looking again at your times, I notice that the CPU% is quite a bit higher on the faster score. I have a sneaking suspicion a cron job or something kicked in while you were running the second one, so it just didn't get as much processor time and took longer.

--Jimbo 11:52, 10 Jul 2005 (EDT)

As my load average is about 1.0, I have done my tests 4 or 5 time to check that the result was always the same (it was)... But it may not have incidence on the statistics since they are updating by the kernel when the process is effectively running and collected by the time command by reading a data structure filled by the wait4() system call (If I don't remember wrong, time fork() itself, exec() the command and wait4() for it)...

What I think is that the execution time can be dependant of the number of results : As I might have everyting up to date, i might have the greater difference I can get (all the ports vs. none)...

Well... I have nothing to conclude from this ... All the two methods do the same :) --Smortex

I'm betting it has to do with your high average load. I generally work with fairly high-powered servers in relatively small environments, with load frequently averaging as low as .05 even during working times. (PS: when you're writing in talk pages, you might want to use the signature button (looks like a little squiggle up at the top of the textarea) to sign your comments, or if you're using a non-graphical browser, you can get the same effect by using --~~~~ as a code.) =) --Jimbo 18:55, 10 Jul 2005 (EDT)