db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1664) Derby startup time is too slow
Date Tue, 07 Sep 2010 20:13:33 GMT

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

Rick Hillegas updated DERBY-1664:

    Attachment: derby_1664.java

Attaching derby_1664.java. This program uses System.currentTimeMillis() to measure how long
the following operations take:

DRIVERLOAD  -- The time to execute Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" )
DBCREATE -- The time to execute DriverManager.getConnection( dbName + ";create=true" );
DBCLOSE -- The time to execute DriverManager.getConnection( dbName + ";shutdown=true" );
REOPEN -- The time to execute DriverManager.getConnection( dbName );
TABLECREATE -- The time to execute Connection.prepareStatement( "create table t( a int )"

Each run of the program creates a configurable number of databases, performing the above operations.
The first database takes the longest, presumably because it involves faulting in a lot of
Derby classes. The program can be run against on-disk and in-memory databases. I ran the program
10 times for on-disk and 10 times for in-memory databases. For each run, I created 10 databases.
I then ran the accumulated log script to generate the following results. I ran this test on
my macbook pro laptop (10.7 trunk on Java 7 on Mac OSX 10.5.8).

This is the script I used to drive the program:

rm derby_1664.sql

for counter in 0 1 2 3 4 5 6 7 8 9
    echo Run number $counter...
    java derby_1664 $counter memory 10
    java derby_1664 $counter disk 10

These are the performance numbers for the first database, the one which incurs the brunt of
the classloading. The numbers are averaged over the 10 runs of the program. The first column
describes the configuration, which is either DISK (on-disk databases) or MEMORY (in-memory

CONFIGURA&|DRIVERLOAD          |DBCREATE            |DBCLOSE             |REOPEN     
DISK      |450                 |1123                |36                  |33             
MEMORY    |496                 |950                 |11                  |20             

These are the performance numbers averaged over the subsequent databases, again averaged over
the 10 runs of the program:

CONFIGURA&|DRIVERLOAD          |DBCREATE            |DBCLOSE             |REOPEN     
DISK      |0                   |486                 |13                  |22             
MEMORY    |0                   |267                 |5                   |14             

I am puzzled that DRIVERLOAD consistently takes longer for in-memory databases than for on-disk

> Derby startup time is too slow
> ------------------------------
>                 Key: DERBY-1664
>                 URL: https://issues.apache.org/jira/browse/DERBY-1664
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>            Reporter: David Van Couvering
>         Attachments: derby_1664.java, perftest.diff
> I know it's hard to measure what "too slow" is, but this is a common complaint and this
affects overall perception of Derby.  This appears to be related to another common complaint
that it takes too long to create tables.  I am marking this as Urgent because of the impact
it has to Derby perception and the fact that the 10.2 release is going to get such wide distribution
through the Sun JDK.
> For background, see http://www.nabble.com/Startup-time-tf2012748.html#a5531684

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

View raw message