Supposed fix to #317518: New version of libsql-statement-perl is very, very much slower

[Paul Beardsell]

Jens,

This is the second time that the bug I reported has been said to be fixed.
The first time (v1.14) the performance had got worse, not better.  It took
me a lot of effort to work that out.  Installing and uninstalling software
so as to run benchmarks, with the same data etc etc is time consuming, so
you will understand my disappointment.

Before doing all that work again I thought it would be interesting to see
the nature of Ty's patch.  It looked good (worthy of performance testing) to
me.

But the patch supplied by Ty was not applied.  Now, I am not one of those
like you spending a lot of time on this and related packages for the benefit
of others (thank you!), but if we're going to close the bug off and SAY the
patch has been applied, then it should have been applied.

If the real reason for closing the bug report is that the code is now
completely re-written in 1.22 and it is impossible to apply the patch, and
that maybe the new code is quicker than any recent version anyway, then that
should be the reason quoted for closing the bug, not the reason actually
given.

I re-iterate:  The patch was not applied to 1.15 (where the important bits
appear but are commented out) and was similarly not fully applied to 1.18.
Therefore I submit it was unlikely to have been applied to 1.16, as reported
in the bug "fix".  [I cannot find that version of the code, however.]

That's my point:  If the bug is being closed off and the stated reason is
that the patch has been applied, then the patch must be applied.  It's a
small but important point, and I labour over it, but I respond to your
question:  You asked what the purpose of my e-mail was.

Regards,
Paul

Paul Beardsell
Paul at Beardsell.com


2009/10/21 Jens Rehsack <rehsack at googlemail.com>

> 2009/10/20 Paul Beardsell <paul at beardsell.com>:
> > Please refer http://rt.cpan.org/Public/Bug/Display.html?id=16579
> >
> > I've been looking at the source code of various versions of
> SQL::Statement.
> >
> > Ty suggested a number of patches to address the performance problems I
> > reported.  He supplied a patch file.
> >
> > My bug report "#317518: New version of libsql-statement-perl is very,
> very
> > much slower" has been closed and the reasoning goes as follows.  The last
> > Debian version was 1.5, the next version in Debian is 2.*, and the patch
> is
> > reported as being applied in version 1.16.2.  I can't find the 1.16.2
> code
> > but I have found the 1.18 code.  Much of the patch is *not* to be found
> in
> > 1.18
>
> The patch from RT #16579 has been applied in 1.16_02 (I did that). Maybe
> your
> patch wasn't so optimal that I did more optimization after it?
> Anyway - since 1.22, process_predicate is obsoleted and replace by much
> quicker code.
>
> > The differences from 1.* to 2.* code are too great for me to get my head
> > around in a short time, but I suspect if the patch is NOT to be found in
> > 1.18, and it was reported as beinbg done in 1.16, that it is also not to
> be
> > found in 2.*
>
> Thanks that you see that a lot of work has been done from 1.15 to 1.22.
> Without having timed the performance increase of my first patch in 1.16_1
> (because it primarily addresses big implicit joins over dozen of tables),
> the
> improvement from 1.20 to 1.21_1 is measured with 15%-20% speed
> improvement (depending on the query, and I used hand optimized
> pseudo-indexes on the used tables - with DBD::CSV it should speed up more),
> the changes from 1.21_1 - 1.22 improve the primary change in 1.21_1, add
> native
> IN and BETWEEN support (reduced SQL compare operations) and so on.
>
> The question which I cannot answer by myself: what do you try to argue with
> this
> mail? Did you measure with the new release(s) or do you try to understand
> each
> change before?
>
> /Jens
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20091021/10cd315f/attachment-0001.htm>