Hi!
----
Is it possible to use |recv()| in Solaris on a normal pipe (see attached
email, it may be somewhat performace-critical for shell scripts) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
--- Begin Message ---
> Hi,
>
> The attached script contains two methods for writing out the process
> table and filtering out some processes using patterns or REs.
>
> I was a bit surprised to find that the real and sys times for do_NEW
> were about 7 and 9 times respectively that of do_OLD.
> I thought that the fork/exec's of all those greps and tee would be steep
> compared to the internal while read loop and the case
> filter, but apparently it is just the opposite.
>
> This was run on a fast Intel-based blade server with Red Hat Linux AS 3
> kernel 2.4.21-32.0.1
>
> But wait. I was running the stock /bin/ksh Version M 1993-12-28 n+ for that
> test
> .
>
> I re-tested with my private copy of ksh93 Version M 1993-12-28 r .
> I was amazed to see the do_NEW times shrink to that of the do_OLD times.
>
> I'm curious to know what was done between those two releases to improve
> the performance so much.
> Whatever it was, nice work! :-)
>
> Regards,
> Mario DeFazio
>
> #!/bin/ksh
>
> TARGDIR=.
> Timestamp=$(date '+%m/%d/%Y %H:%M:%S')
> Host=$(hostname)
> DURATION='00:00:60'
> HOUR=$(date '+%H')
>
>
> function do_OLD
> {
>
> OUTPUTFILE=data.out.OLD
>
>
> ps h -eo "[EMAIL PROTECTED]@[EMAIL PROTECTED]
> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]" |
> grep -v "ps h -eo" | grep -v "#root *#" | grep -v "#bin *#" |
> grep -v "#nobody *#" | grep -v "#daemon *#" | grep -v "grep -v" |
> tee -a ${TARGDIR}/${OUTPUTFILE} > /dev/null
>
> }
>
> function do_NEW
> {
>
> OUTPUTFILE=data.out.NEW
>
> # Open output file for append
> #
> exec 5>>${TARGDIR}/${OUTPUTFILE}
>
> ps h -eo \
> "[EMAIL PROTECTED]@[EMAIL PROTECTED]
> [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]" |
>
> while read Line
> do
> case "$Line"
> in
> # skip a bunch of entries
> #
> *'ps h -eo'*|\
> *'grep -v'*|\
> *#root+( )#*|\
> *#bin+( )#*|\
> *#nobody+( )#*|\
> *#daemon+( )#*)
> continue
> ;;
> esac
>
> # Save everything else
> #
> print -u5 "$Line"
> # print "$Line"
> done
> }
>
> time do_OLD
> time do_NEW
>
I am not certain but since it was Linux I suspect the following:
The
command | while read ;do...;done
is a problem for the shell. The problem is that if there are any
commands between do and done, then the shell doesn't know whether
any of these use standard input and therefore cannot do read-aheads.
Therefore, the read comamnd cannot read past the new-line.
On systems that allow recv() on a pipe, it can peek ahead
to find the new-line and read() can read() a line at a time.
Otherwise, it needs to read a byte at a time.
The problem is that Linux doesn't allow recv() on a pipe.
We changed ksh93 to use socket pairs rather than pipes
in most cases and then it can read a line at a time.
This can make a big difference.
In this particular case, since you only have built-ins in
the do...done list, theoretically the shell could be optimized
to detect this and to allow read-ahead but I don't have
code to catch this and I don't know how easy it would
be since you can call functions of the same name as built-ins.
It is possible to write this so that it can do full buffering
read-ahead, but only true shell experts are know to do this.
If you had written
ps | while read -u9; do ...;done 9<&0-
This would have moved the standard input of the while loop
to unit 9 and then closed standard input. Then, ksh93
would know that it is save to use full read ahead since no
other process can access the stream.
Finally, you might get better performance by combining
some of the patterns,
*#root+( )#*|\
*#bin+( )#*|\
*#nobody+( )#*|\
*#daemon+( )#*)
can be replaced by
*#@(root|bin|nobody|daemon)+( )#*)
which should be a little faster.
David Korn
[EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[EMAIL PROTECTED]
https://mailman.research.att.com/mailman/listinfo/ast-users
--- End Message ---
_______________________________________________
perf-discuss mailing list
[email protected]
