Jens,<br><br>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.<br>
<br>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. <br><br>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.<br>
<br>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.<br>
<br>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.]<br>
<br>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.<br>
<br>Regards,<br>Paul<br><br clear="all">Paul Beardsell<br>Paul@Beardsell.com<br>
<br><br><div class="gmail_quote">2009/10/21 Jens Rehsack <span dir="ltr"><<a href="mailto:rehsack@googlemail.com">rehsack@googlemail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/10/20 Paul Beardsell <<a href="mailto:paul@beardsell.com">paul@beardsell.com</a>>:<br>
<div class="im">> Please refer <a href="http://rt.cpan.org/Public/Bug/Display.html?id=16579" target="_blank">http://rt.cpan.org/Public/Bug/Display.html?id=16579</a><br>
><br>
> I've been looking at the source code of various versions of SQL::Statement.<br>
><br>
> Ty suggested a number of patches to address the performance problems I<br>
> reported. He supplied a patch file.<br>
><br>
> My bug report "#317518: New version of libsql-statement-perl is very, very<br>
> much slower" has been closed and the reasoning goes as follows. The last<br>
> Debian version was 1.5, the next version in Debian is 2.*, and the patch is<br>
> reported as being applied in version 1.16.2. I can't find the 1.16.2 code<br>
> but I have found the 1.18 code. Much of the patch is *not* to be found in<br>
> 1.18<br>
<br>
</div>The patch from RT #16579 has been applied in 1.16_02 (I did that). Maybe your<br>
patch wasn't so optimal that I did more optimization after it?<br>
Anyway - since 1.22, process_predicate is obsoleted and replace by much<br>
quicker code.<br>
<div class="im"><br>
> The differences from 1.* to 2.* code are too great for me to get my head<br>
> around in a short time, but I suspect if the patch is NOT to be found in<br>
> 1.18, and it was reported as beinbg done in 1.16, that it is also not to be<br>
> found in 2.*<br>
<br>
</div>Thanks that you see that a lot of work has been done from 1.15 to 1.22.<br>
Without having timed the performance increase of my first patch in 1.16_1<br>
(because it primarily addresses big implicit joins over dozen of tables), the<br>
improvement from 1.20 to 1.21_1 is measured with 15%-20% speed<br>
improvement (depending on the query, and I used hand optimized<br>
pseudo-indexes on the used tables - with DBD::CSV it should speed up more),<br>
the changes from 1.21_1 - 1.22 improve the primary change in 1.21_1, add native<br>
IN and BETWEEN support (reduced SQL compare operations) and so on.<br>
<br>
The question which I cannot answer by myself: what do you try to argue with this<br>
mail? Did you measure with the new release(s) or do you try to understand each<br>
change before?<br>
<font color="#888888"><br>
/Jens<br>
</font></blockquote></div><br>