Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1578045067.1243015545636.JavaMail.jira@brutus>
Date: Fri, 22 May 2009 11:05:45 -0700 (PDT)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4233) Lower tablescan performance right
 after database creation in 10.5
In-Reply-To: <1362997583.1242642825551.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4233:
----------------------------------


Not sure what is going on here, but wanted to comment on the next+fetch -> fetchNext() change.  The fetchNext() interface was specifically added (a long time ago) as a performance enhancement and is definitely  preferred whenever it can be substitued for a next + fetch call.
It saves both procedure calls, code execution and number of times latches are required.

If someone wants to do more work on this one, it does seem likely this is some sort of jit issue.  So maybe experimenting with setting jvm options that start jit'ing earlier on both before and after change may show up something.

> Lower tablescan performance right after database creation in 10.5
> -----------------------------------------------------------------
>
>                 Key: DERBY-4233
>                 URL: https://issues.apache.org/jira/browse/DERBY-4233
>             Project: Derby
>          Issue Type: Bug
>          Components: Performance, SQL
>    Affects Versions: 10.5.1.1
>         Environment: Solaris Express Community Edition snv_114 X86
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>
> I noticed that a table scan test performed significantly worse
> (10-20%) in Derby 10.5.1.1 than in Derby 10.4.2.0. I only see this if
> the test creates and populates a fresh database. To reproduce, put
> derbyTesting.jar from 10.5.1.1 and derby.jar from the release you want
> to test in your classpath, and execute the following shell commands:
> # make sure the database is removed so that we create a fresh one
> test -d db && rm -rf db
> # run test for five minutes (+ one minute warm-up)
> java -server -Dderby.storage.pageCacheSize=25000 \
>     org.apache.derbyTesting.perf.clients.Runner \
>     -load sr_select -load_opts nonIndexed -wt 60 -rt 300 -init

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