db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2657) Performance regression after check-in of svn 531971
Date Tue, 12 Jun 2007 09:08:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503786

Knut Anders Hatlen commented on DERBY-2657:

I ran Olav's test client against revision 531970 and revision 531971, and used DTrace to monitor
object allocations. What jumped out, was that revision 531971 allocated a large number of
ProtocolKey objects. It turns out this is caused by Xact.getDataValueFactory() which was introduced
in that revision. Instead of returning the value of its dataValueFactory field, it invokes
Monitor.findServiceModule() which creates a ProtocolKey object that is used in a Hashtable
look-up. When I changed that method so that it just returned dataValueFactory, I didn't see
the difference in performance between the two revisions any more.

> Performance regression after check-in of svn 531971
> ---------------------------------------------------
>                 Key: DERBY-2657
>                 URL: https://issues.apache.org/jira/browse/DERBY-2657
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Solaris/Linux, Sun JDK 5 & 6, IBM 1.5
>            Reporter: Olav Sandstaa
>             Fix For:
>         Attachments: TestClient2.java
> After check-in of svn 531971 on DERBY-2537 it seems like there for
> some loads are a performance regression of about 10-15 percent.
> For more info about this issue see the following mail thread:
> http://www.nabble.com/Performance-regression-after-check-in-on-DERBY-2537-(SVN-531971)-t3651494.html

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

View raw message