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--
> 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--