On Wednesday, December 29, 2010 16:35:24 Max Maischein wrote:
> I'm not sure what the downsides to this would be, except the small speed
> hit. Existing C/XS code that calls fork(3) might already do the
>
> SvREADONLY_off(dollardollar);
> sv_setiv(dollardollar,getpid())
> SvREADONLY_on(dollardollar);
I believe the performance hit of calling getpid is quite small since glibc
also caches the actual PID, see
http://www.kernel.org/doc/man-pages/online/pages/man2/getpid.2.html#NOTES
But I am not sure if it is a good idea to perform the actual syscall.
$ perl -MBenchmark=:hireswallclock -e '
sub gp { return $$ }
Benchmark::cmpthese Benchmark::timethese 750, {q{$$} =>sub {$x=$$ for(1..100000)},
sub =>sub {$x=gp for(1..100000)},
syscall=>sub {$x=syscall 39 for(1..100000)}}'
Benchmark: timing 750 iterations of $$, sub, syscall...
$$: 6.32676 wallclock secs ( 6.24 usr + 0.03 sys = 6.27 CPU) @ 119.62/s (n=750)
sub: 22.2411 wallclock secs (21.92 usr + 0.13 sys = 22.05 CPU) @ 34.01/s (n=750)
syscall: 16.5083 wallclock secs (12.13 usr + 4.24 sys = 16.37 CPU) @ 45.82/s (n=750)
Rate sub syscall $$
sub 34.0/s -- -26% -72%
syscall 45.8/s 35% -- -62%
$$ 120/s 252% 161% --
Just my 2 ¢.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Thread Previous
|
Thread Next