Simultaneous multiple module versions

[Nicholas Clark]

On Thu, Aug 17, 2006 at 10:16:59PM +0100, Matt S Trout wrote:
> Nicholas Clark wrote:
> >It's not a "fix", as it fixes a real bug, and not a Class::DBI specific 
> >bug.
> 
> Your version I consider a bugfix. Red Hat's dumbass backport to a version 
> that can't handle it properly and where everybody expects to have to work 
> around the damn bug anyway gets the quote marks.

> Is any response required from you? This isn't in the real perl, only a 
> specific mutant Red Hat one, so I figured it was their problem, not yours.


No, the important part is that it's my solution, and wasn't supposed to be
dumbass, because:

On Thu, Aug 17, 2006 at 04:53:05PM +0100, Nicholas Clark wrote:

> So, bless ({}, $class) shouldn't be affected, as there will be only one
> reference to that {}

but *that* turned out not to be true.
With that assumption wrong, performance tanks.

Thanks for causing me to investigate this. Possibly Red Hat should have dug
a bit deeper...

> No-one's reported the performance hit upstream, let alone with a demonstration
> case that uses only core modules. Is anyone surprised that there's been
> no response?

Specifically, the way that the core has been producing the anonymous hash
for {} (or anonymous array for []) is to run these two operations:

1: Create an anonymous array. Push it on the stack.
2: Take a reference to it. Push that reference on the stack

Note that because items on the perl stack are not reference counted via the
stack itself, all that pushing means that those items are mortals
(A reference to the item is pushed onto the temp stack, and gets freed "later",
by which time the stack frame will have been unwound, hence the object says
around with non-zero reference count for long enough)

[Actually there was a pushmark op too, making 3 ops for this one action]

Note that we have two stacked items. Two reference counts. Breaks my
assumption. But also means 2 items on the temp stack to deal with, and we
used 3 ops to get here. I stuck the debugger on the static function and
it got called when I assumed that it should not.

So I changed the ops for generating anonymous arrays and hashes to optionally
generate references directly instead. 1 reference on the stack. My assumption
holds again. [er, OK, I've not benchmarked that it does, but I stuck the
debugger on the static function and it doesn't get called]

Merged to maint about 3 weeks ago:

http://public.activestate.com/cgi-bin/perlbrowse/28775

I hope that Red Hat ship this bug fix to my bug fix.

It has this side effect that all [] and {} everywhere are slightly faster.
Anyone care to send a patch to perlbench to benchmark this? :-)

Nicholas Clark

PS We like this: http://use.perl.org/~Matts/journal/31087