get process id

Sun Oct 10 16:47:27 PDT 2004

This public service announcement was brought to you by Brian K. White:
> 
> And, since I thought using perl just for that offended my sense of 
> efficiency because the same thing is built-in in ksh and I thought ksh  just 
> _has_ to be a lot lighter and faster to load & run than perl and besides 
> that, every box, even really old boxes, clear back to Xenix, already has ksh 
> and it's not so easy to get perl on some old sco boxes....

*laugh*  You didn't look very hard at how light and fast bash is compared
to perl, did you?  Witness OSR 5.0.6 with:

> ls -l /opt/K/SCO/Unix/5.0.6Ga/bin/ksh
---x--x--x   1 bin      bin       156764 Feb 14  2003 /opt/K/SCO/Unix/5.0.6Ga/bin/ksh*

> ls -l /opt/K/SCO/perl/5.8.1Ac/usr/bin/perl
-rwxr-xr-x   2 bin      bin         9668 Jul  5 21:22 /opt/K/SCO/perl/5.8.1Ac/usr/bin/perl*

Yup.  Ksh is -so- much lighter, Brian.

> So I did a Stockler and came up with:

Feeling particularly modest and humble today, are you?

> last pid: 24662;  load averages:  0.33,  0.14,  0.08 
> 18:00:39
> 125 processes: 110 sleeping, 2 running, 12 zombie, 1 onproc
> CPU states:  0.0% idle, 43.2% user, 56.6% system,  0.2% wait,  0.0% sxbrk
> Memory: 1024M phys, 897M max, 832M free, 873M locked, K unlocked, K swap
> 
> just before the end of the ksh run, top showed:
> last pid: 29386;  load averages:  0.29,  0.15,  0.08 
> 18:01:29
> 125 processes: 110 sleeping, 2 running, 12 zombie, 1 onproc
> CPU states:  0.0% idle, 26.4% user, 73.6% system,  0.0% wait,  0.0% sxbrk
> Memory: 1024M phys, 897M max, 832M free, 873M locked, K unlocked, K swap

No big deal.  Like that extra 0.04 will kill someone.  If 0.04 is a serious
matter to someone, their system has far bigger problems than perl vs ksh.

> And the timings output from above were:
> # timeperl
> Sun Oct 10 18:00:16 EDT 2004
> Sun Oct 10 18:00:40 EDT 2004
> # timeksh
> Sun Oct 10 18:01:14 EDT 2004
> Sun Oct 10 18:01:31 EDT 2004

blip.pl:
     #/usr/local/bin/perl
     print(getppid(),"\n");
     exit(0);

time perl -e 'for ($x=0;${x}<5000;$x++){$outbuf = `./blip.pl`;}'
34.440u 32.560s 1:13.08 91.6%   0+0k 0+0io 1280228pf+0w

7:26pm  up 10 days, 11 min, 10 users,  load average: 0.80, 0.40, 0.23
92 processes: 91 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  4.5% user,  3.0% system,  0.0% nice,  3.0% idle
Mem:   127776K av,  124392K used,    3384K free,   46024K shrd, 29192K buff
Swap:  131448K av,   21204K used,  110244K free                 31152K cached

That's a tiny K6-450 with 128MB running linux with a 2.2 kernel.  That box
is doing very disk-intensive work--using software RAID, which makes the
system a bit slower than usual, unfortunately.  I have no idea what you
were using.

> Note: the "before either" isn't _really_ before. I had run almost the same 
> jobs a few times each already and so perl was already loaded into ram and 
> probably not discareded yet. ksh will always be in ram since on my boxes 

Perl was probably not resident on mine, or was mostly uncached, based on
what the system is actually doing--a lot of disk-intensive work, and
there's the fact that I hadn't used perl since Friday afternoon.

After the first iteration, swap is pretty irrelevant unless your box is
churning away on disk I/O like mad.

> I'm quite nettled to have to admit I see little reason to avoid using perl 
> for this other than the issue of simply _getting_ perl on old sco boxes. But 
> in truth, if you are willing to accept older versions of perl, it's pretty 
> easy even on older boxes as long as there is HD space (it winds up in / 
> which many times has very little spare room and it's _bad_ when / gets full) 
> and you have some way to get several megs of package files onto the box.

My complaints about the SCO 5.0005 version from Skunkware are many.  I have
no cause for complaint with the 5.8.1 they've provided for sufficiently
updated 5.0.[67] systems, however.  The very fact that it actually runs
with modules that embed C libraries--modules you've compiled yourself, such
as XML::Parser [actually, they now include that themselves] and
Curses--instead of claiming it can't locate the .so when it's plainly there
is in and of itself a huge plus.

If you're -really- concerned about "light and fast", it's about as simple in
C as it is in perl:

#include <stdio.h>
int main() {
     printf("%d\n",getppid());
     exit(0);
}

There.  Compile that and you have a single executable that -only- does that
specific task with the barest possible extra bloat.

time perl -e 'for ($x=0;${x}<5000;$x++){$outbuf = `./a.out`;}'
7.830u 15.210s 0:25.74 89.5%    0+0k 0+0io 390228pf+0w

Cuts the time -way- down.  Of course, someone has to have a devkit
installed.  :)

Of course, they could just include pid() and ppid() functions in fP 5.1 and
eliminate all of this nonsense altogether.  *HINT to the parties involved*
Enough people have wanted it over time.  How about unixtime() as well, for
obtaining a proper *nix timestamp?  That's LONG overdue.  Between those, we
would actually be able to generate truly unique values internally--finally.
And I -know- I'm not the only person (by a large margin) that's had this
requirement for quite some time.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html