[Dbix-class] [ANNOUNCE] DBIx::Class 0.08008

[Brandon Black]

On Nov 19, 2007 4:07 AM, Bernhard Weißhuhn <bkw at weisshuhn.de> wrote:
> On Mon, Nov 19, 2007 at 11:16:00AM +1030, Jon Schutz <jon+dbix at youramigo.com> wrote:
>
> > Unfortunately, after the upstream fix, the performance penalty is still
> > 2-4x.  Prior to the fix, it was 8-12x.  Relative benchmarks including
> > 5.8.8-24 were posted in
> > http://lists.scsys.co.uk/pipermail/dbix-class/2007-October/005119.html
>
> OIC. Sorry I overlooked Your analysys and thanks for pointing it out again.
>
> Maybe You could add your findings to redhats bugzilla (196836),
> which currently suggests the problem to be fixed since 5.8.8-22, which
> obviously is not the case.
>

It probably won't do much good, it's not like RH could easily make the
situation any better now.  If I'm understanding things correctly, any
dist that ships 5.8.9 (not out yet) will have the same issues as the
newest RH 5.8.8's too.  This is my current understanding of the four
possible states a given Perl distribution could have wrt this issue:

1. Has the original bug, but no performance issues:  Vanilla 5.8.8 and
earlier, and most vendor-supplied builds of the same.
2. Has the bug fixed, but with big performance issues: The redhat
5.8.8 builds that fall in a certain range of redhat sub-release
numbers.
3. Has the bug fixed, with minor performance issues: Newer redhat
5.8.8 builds, vanilla 5.8.9 (and presumably all 5.8.x where x >= 9).
4. Has the bug fixed, without a performance issue: 5.10.0+

Currently our StartupCheck code is going to warn in case 2, and in the
subset of case 3 where the perl version is still 5.8.8.  I don't think
there's much point complaining about the 5.8.9+ case, as it will be
the vanilla default behavior for those releases, although perhaps we
could update the docs to clarify that the (relatively minor) perf
issue will exist in those releases as well).  Might be a bit premature
for it though, since 5.8.9 hasn't actually been released yet, and
anything could change before then.

-- Brandon