[Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux

[Nigel Metheringham]

Red Hat carried a duff patch in their perl builds for RHEL5 and Fedora 5
though 7 (I think) for a period of time. The original patch was intended
to deal with a real problem which affected certain combinations of
bless/overload - see
   http://rt.perl.org/rt3/Public/Bug/Display.html?id=34925

However it had nasty effects in that a brute force search of blessed
objects could happen under certain circumstances, leading to a
exponential slow down for certain usage patterns.

The Fedora issues were fixed in a Fedora 7 update in 2007.
   https://bugzilla.redhat.com/show_bug.cgi?id=196836

The issues in RHEL5 were finally fixed recently
   https://bugzilla.redhat.com/show_bug.cgi?id=379791

RHEL4 has never had this problem with a system perl, although the perl
build for RHEL4 does have other issues (eg include paths and vendor/site
ordering).


DBIx::Class::StartupCheck
-------------------------

Both old and new perls trigger the startup check - as will any perl with
the fixes to bless/overload bugs that is less than version 5.8.9. Other
than doing performance checks, which would be prohibitively cpu
intensive, I cannot think of a method for identifying this problem in
the startup check code without hitting a lot of false positives. I see
that this code is patched out in rpm distributions of DBIx::Class. I am
wondering if the checks have now outlived their usefulness, at least as
a by default option. Maybe they should be added to the test suite
instead.


DBIC Benchmarks
---------------

The benchmark I am using is a simple pair of tables where set up so you
can do a join-ed query on them. The resultset search parameters for each
benchmark are tweaked to ensure the same SQL is generated, but they
differ in what they do with the returned rows:-
   hashrefi_all:
     grabs the rows as a 2 level hash (prefetched) using
     DBIx::Class::ResultClass::HashRefInflator
     This is the "we don't need no stinking objects" version
   join_all:
     Only inflates the main RS objects - throws away the second level
   prefetch_all:
     Grabs and inflates all objects

These benchmarks were run on an identical pair of VMs, the only
difference being the installed perl version.

The newer perl is fractionally slower on the hashref based benchmarks
but significantly faster on the object based ones. Some more contrived
examples show greater differences.

Centos 5.2, perl perl-5.8.8-10.el5_0.2 (ie release version of perl)
Benchmark: running hashrefi_all, join_all, prefetch_all for at least  
30 CPU seconds...
hashrefi_all: 31.9955 wallclock secs (31.74 usr +  0.08 sys = 31.82  
CPU) @  5.91/s (n=188)
   join_all: 34.6187 wallclock secs (34.40 usr +  0.04 sys = 34.44  
CPU) @  1.83/s (n=63)
prefetch_all: 31.0027 wallclock secs (30.78 usr +  0.03 sys = 30.81  
CPU) @  1.20/s (n=37)

Centos 5.2, perl perl-5.8.8-15.el5_2.1 (update version of perl)
Benchmark: running hashrefi_all, join_all, prefetch_all for at least  
30 CPU seconds...
hashrefi_all: 32.3373 wallclock secs (30.40 usr +  1.12 sys = 31.52  
CPU) @  5.43/s (n=171)
   join_all: 32.5188 wallclock secs (30.22 usr +  1.30 sys = 31.52  
CPU) @  6.38/s (n=201)
prefetch_all: 30.8614 wallclock secs (29.40 usr +  0.63 sys = 30.03  
CPU) @  3.33/s (n=100)



     Nigel.

--
[ Nigel Metheringham             Nigel.Metheringham at InTechnology.com ]
[ - Comments in this message are my own and not ITO opinion/policy - ]