Mailing List Archive

Speed matters (fwd)
I wrote:
> I return again to the topic of SV in your code. If you mention some data
> in your code, it is most probably represented by an SV sitting "inside"
> the interpreter. Let me try three examples:
>
> my $a;
> function(2); # 1
> function($a); # 2
> function($b); # 3
[...]
> In the second case the node of the execution tree does not know the address
> of the SV, but knows the offset in the current "scratchpad":
>
> pushx(curpad[op->op_targ])
[...]
> In the third case the code is
>
> pushx(op->op_gv->sv_any->xgv_gp->gp_sv)
[...]
> PS. Looking on
>
> pushx(curpad[op->op_targ])
> vs
> pushx(op->op_gv->sv_any->xgv_gp->gp_sv)
>
> I would think that the first one will be insignificantly faster. This is
> true on Sparc 5, where speedup is on the boundary of sensibility of unloaded
> machine. However, on i386 it is 4% _slower_! (486dx2)
> Can anyone explain _this_?
>

Nick had some suggestions about local vs. global variable access, that
I find quite suspicious since I do not see how op->op_gv is better
than curpad. On the other hand, he mentioned dynamic linking overhead,
and I tried the same code on statically linked perl (on OS/2 perl.exe
is circa 6K, with 500K DLL, you cannot do dynamic perl modules without
dynamic executable).

With static perl the case 3 is 2% quickier than the case 2, that makes my
suggestion about
use my;
quite viable even without further optimizations (discussed in the
omited parts of my post).

Ilya

PS: tests were
my $a=4000000;1 while $a--
and
$a=4000000;1 while $a--
Re: Speed matters (fwd) [ In reply to ]
: With static perl the case 3 is 2% quickier than the case 2, that makes my
: suggestion about
: use my;
: quite viable even without further optimizations (discussed in the
: omited parts of my post).

Syntactically speaking, I don't think it would be wise to intermix
implicit and explicit declaration of lexicals. And we're already rather
committed to explicit declaration.

Larry