db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5472) Speed up MemoryLeakFixesTest.testRepeatedDatabaseCreationWithAutoStats()
Date Wed, 19 Oct 2011 18:15:10 GMT

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

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

More numbers:

Only 4 (compiling the INSERT statement once and execute multiple times) reduced the time from
85 sec to 58 sec.

Doing 3 (compile/execute the SELECT statement only once) in addition to 4, reduced the time
further down to 12 sec.

So it looks like reducing the amount of compilation is actually more important than reducing
the number of iterations.
                
> Speed up MemoryLeakFixesTest.testRepeatedDatabaseCreationWithAutoStats()
> ------------------------------------------------------------------------
>
>                 Key: DERBY-5472
>                 URL: https://issues.apache.org/jira/browse/DERBY-5472
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions: 10.9.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: d5472.diff
>
>
> MemoryLeakFixesTest.testRepeatedDatabaseCreationWithAutoStats() takes fairly long time.
When I run it with -Xmx16M (per instructions in the comments) in my environment, that test
case alone takes 80-90 seconds. And it runs twice (embedded and client) so it takes nearly
3 minutes in total.
> There are ways to speed it up and still have it expose DERBY-5336, for which it was originally
written:
> 1) The body of the test is executed 50 times. When the fix for DERBY-5336 is backed out,
the test case typically fails in the 8th or 9th iteration, so 20 iterations should be enough.
> 2) In each iteration, a table with 500 rows is created. Since the goal is to get the
istat daemon to run, we only need to insert enough rows to exceed derby.storage.indexStats.debug.createThreshold,
which is 100 by default. Reducing the size to for example 200 rows would be OK.
> 3) When populating the table, a select statement is compiled and executed in between
each insert statement. To get the istat daemon running, it's sufficient to execute a single
select statement once the table is populated.
> 4) Every insert statement is compiled separately. Would be better to compile once and
execute multiple times.
> 5) Populating the table could happen with auto-commit off.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message