On Fri, Oct 06, 2006 at 06:46:20AM -0700, Jerry Hedden wrote:
> Rick Delaney snidely replied:
> > I can see no reason why anyone would believe these numbers
> > without seeing the tests.
>
> Gawd, I love being called a liar first thing in the morning.
> It really gets my blood pumping.
>
> First, let's see just how slow generating a 'default' object
> string is. (I'm going to call this a CTA string because it's
> composed of the Class name, the Type and the Address).
> Results:
> Rate str tid
> str 56.5/s -- -83%
> tid 340/s 502% --
The results are completely counterintuitive.
I too expected that the builtin C code for generating
threads=SCALAR(0x1817fa0) would be faster than going through the overloading
code in Perl_call_amagic, and then that kicking off a nested call to another
routine (which happens to be XS)
What's actually happening is that because threads objects already have some
overloading, then for this stringification of a reference,
Perl_call_amagic gets called *anyway*.
Here's the good bit though:
SV *msg;
if (off==-1) off=method;
msg = sv_2mortal(Perl_newSVpvf(aTHX_
"Operation \"%s\": no method found,%sargument %s%s%s%s",
AMG_id2name(method + assignshift),
(flags & AMGf_unary ? " " : "\n\tleft "),
SvAMAGIC(left)?
"in overloaded package ":
"has no overloaded magic",
SvAMAGIC(left)?
HvNAME_get(SvSTASH(SvRV(left))):
"",
SvAMAGIC(right)?
",\n\tright argument in overloaded package ":
(flags & AMGf_unary
? ""
: ",\n\tright argument has no overloaded magic"),
SvAMAGIC(right)?
HvNAME_get(SvSTASH(SvRV(right))):
""));
if (amtp && amtp->fallback >= AMGfallYES) {
DEBUG_o( Perl_deb(aTHX_ "%s", SvPVX_const(msg)) );
} else {
Perl_croak(aTHX_ "%"SVf, (void*)msg);
}
return NULL;
We make a message. Only it's never getting used. But we went to all the
effort.
It will be a SMOP this evening to get rid of creating that message
needlessly. Which might change the benchmark results. Unless anyone wishes
to beat me to it.
Nicholas Clark
