Re: [Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux
On Thu, Oct 02, 2008 at 02:34:10PM +0100, Nigel Metheringham wrote: 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. Nobody will see the warning then. I think the correct approach is probably to identify what in perl -V output indicates a fixed perl as opposed to a broken one, and provide that in the warning so people know when it's safe to set the env var. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
Re: [Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux
On 5 Oct 2008, at 12:00, Matt S Trout wrote: On Thu, Oct 02, 2008 at 02:34:10PM +0100, Nigel Metheringham wrote: 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. Nobody will see the warning then. A run time check of this type is realistically only aiming at those using a system perl and their own cpan install - and you would hope that those people would at least look at any test suite failures on install. The test suite failures should be noticed by rpm packagers as the standard packaging tools do run the test suites on built. I think the correct approach is probably to identify what in perl -V output indicates a fixed perl as opposed to a broken one, and provide that in the warning so people know when it's safe to set the env var. Unfortunately I don't think there is anything I can identify in perl - V which acts as a differentiator. There is definitely no patch information in the output for the rpm built perls, so everything ends up being hopeful guesswork. I don't like it any more than you do, but we seem to be between a rock and a hard place here :-/ I'll recheck this more thoroughly on Monday when I can get at my test systems again (and am not suffering terminal man flu). Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
Re: [Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux
On Sun, Oct 05, 2008 at 04:16:32PM +0100, Nigel Metheringham wrote: On 5 Oct 2008, at 12:00, Matt S Trout wrote: On Thu, Oct 02, 2008 at 02:34:10PM +0100, Nigel Metheringham wrote: 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. Nobody will see the warning then. A run time check of this type is realistically only aiming at those using a system perl and their own cpan install - and you would hope that those people would at least look at any test suite failures on install. Oh, we could fail tests, yes. But we were hoping not to do that. Possibly we could check if we can prompt() and let people hit yenter to make the test pass if they really want it to? Hmm. Or do the prompt at Makefile.PL time would probably be nicer. We could even write Module::Install::RedHatBug ... Unfortunately I don't think there is anything I can identify in perl - V which acts as a differentiator. There is definitely no patch information in the output for the rpm built perls, so everything ends up being hopeful guesswork. Er. There really should be something in registered patches. I could've sworn that they usually did show that. If not then I think the prompt approach is probably the least unsane, unless anybody has a better idea ... -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
[Dbix-class] DBIx::Class and Red Hat perl bugs and performance redux
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 [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
