get process id

[Brian K. White]

Fairlight wrote:
> 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->


You will laugh, but I actually find the c file the most desireable.
It's easier to use and lighter/faster than either the ksh or perl, thus:
http://www.aljex.com/bkw/filepro/#myppid

Too bad for the Windows users who don't have any such thing as the user() 
command.
nya nya :P

But we are going for fast & light. Why'd you use that bloated 90% 
unneccesary printf and %d ?
Lazy? heh :)

I like the idea of a minimalist agent like this to do things filepro can't 
do but simpler & smaller and less possibility of problems than opening say a 
user to a shell or bc etc... and issuing commands and trying to parse the 
responses reliably.
What else doesn't fp provide that we can put in this little agent?
We could change it so it does listen,answer,loop so that to get pid you tell 
it "pid" first and then read, then it can sit there ready to respond to some 
other command.
It's easy to stay in sync wih user commands that have a simple 1:1 
correlation of write:read like that and unlike most other things, here we 
have the source and it's simple and the util's only purpose in life is to 
serve as a user command, and so it's easy to garuntee that the program will 
always adhere to the pattern. That makes it more reliable for user than 
anything.

And you were out of line implying I missed something obvious by showing the 
on-disk executable file sizes.
What matters is the memory usage:



I opened up a single perl interactively and didn't issue any commands (so, 
presumably, it shouldn't have loaded any modules and this should be a 
best-case scenario, I assume your one-liner is also entirely built-in)
# ps -eovsz,size,comm |grep perl
2384  248 perl
# ps -eovsz,size,comm |grep ksh
1008  160 ksh

(I had about 9 identical ksh lines)

Ahem!

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani