[9fans] plan9ports performance

[9fans] plan9ports performance

[a]

does this seem normal?

: unix; time sed -e 's/e/E/g' fortunes > /dev/null
0.01u 0.02s 0.03r        sed -e s/e/E/g fortunes
: unix; time 9sed -e 's/e/E/g' fortunes > /dev/null
0.17u 0.00s 0.17r        9sed -e s/e/E/g fortunes

the difference seems to get greater (percentage) with more
complicated scripts (although i don't have an example that
is more complicated without hitting unix/plan9 sed
differences).

is this just the inherent cost of adding another abstraction
layer, is there something in the plan 9 sed version, or is
something buggered on my system?
ア

Re: [9fans] plan9ports performance

[boyd, rounin]

> does this seem normal?

UTF-8/Runes?

Re: [9fans] plan9ports performance

[Rob Pike]

the implementation of regexps in the plan 9 library is pretty pokey.
it's nice and short but it is not fast.

that said, the factor of 5 to look at a single character seems a little
high. not impossibly high, but high.

-rob

Re: [9fans] plan9ports performance

[Russ Cox]

> : unix; time sed -e 's/e/E/g' fortunes > /dev/null
> 0.01u 0.02s 0.03r        sed -e s/e/E/g fortunes
> : unix; time 9sed -e 's/e/E/g' fortunes > /dev/null
> 0.17u 0.00s 0.17r        9sed -e s/e/E/g fortunes

you could rewrite things to avoid the need to
zero Resublists so much.  it's hard to get excited
about it.

t23=; profile 9sed s/e/E/g fortunes >/dev/null
 0.7%	/usr/local/plan9/bin/9sed:executable
 1.4%	/usr/local/plan9/bin/9sed:Bputc
 1.4%	/usr/local/plan9/bin/9sed:putline
 1.4%	/usr/local/plan9/bin/9sed:rregexec9
 2.0%	/usr/local/plan9/bin/9sed:Bputrune
 2.7%	/usr/local/plan9/bin/9sed:Bgetrune
 2.7%	/usr/local/plan9/bin/9sed:_renewmatch
 2.7%	/usr/local/plan9/bin/9sed:_rrenewemptythread
 2.7%	/usr/local/plan9/bin/9sed:gline
 6.8%	/usr/local/plan9/bin/9sed:Bgetc
11.5%	/usr/local/plan9/bin/9sed:dosub
14.2%	/usr/local/plan9/bin/9sed:_renewthread
18.2%	/usr/local/plan9/bin/9sed:rregexec1
31.8%	/lib/tls/libc-2.3.2.so:memset
t23=;

russ

Re: [9fans] plan9ports performance

[boyd, rounin]

> on the other hand, it could be worse.  look at gnu grep:

yeah, i'll bet all the time is spent in the arg processing code ;)