[jira] Commented: (DERBY-4227) performance degradation of 10.5.1.1 with simple queries & no data retrieval

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708808#action_12708808 ] 

Knut Anders Hatlen commented on DERBY-4227:
-------------------------------------------

I'm wondering if this could be the same that we see in the nightly performance regression tests, mentioned here: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200904.mbox/%3cwjo8vdon4vco.fsf_-_@sun.com%3e

Those tests also perform table scans, similar to the repro class you uploaded, but the performance drop seen there is much smaller than what you report.

> performance degradation of 10.5.1.1 with simple queries & no data retrieval
> ---------------------------------------------------------------------------
>
>                 Key: DERBY-4227
>                 URL: https://issues.apache.org/jira/browse/DERBY-4227
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.5.1.1, 10.6.0.0
>            Reporter: Myrna van Lunteren
>         Attachments: scanperf.java
>
>
> I have been executing some non-contributed (and not easily contributable) performance tests, and found that across the board, with the exception of some blob streaming and complicated queries, 10.5.1.1 performs significantly worse from 10.4.2.0.
> I've turned one of these tests into a little repro script.
> It's decidedly hokey, but if you execute this repeatedly (removing the wombatC db and derby.log each time) you'll likely find the same. I executed this on an MS-Windows 2000 machine, with ibm 1.5. jvm.
> As a quick comparison, I got the following data out of executing the repro 4 times with a fairly recent 10.3.3.1 build (706492), 10.4.2.0, and 10.5.1.1. Time is the elapsed time printed out at the  end by the repro.
> version     10.3.3.1       10.4.2.0     10.5.1.1
> 1st run      187               219             328
> 2nd run     172               172             328
> 3rd run       203              234             313
> 4th run       187               281            344
> We should identify why a simple select without actually fetching the data would do so much worse with 10.5.1.1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.