Re: [RFC] Stringify a thread

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