[
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: 10.3.0.0
> Environment: Solaris/Linux, Sun JDK 5 & 6, IBM 1.5
> Reporter: Olav Sandstaa
> Fix For: 10.3.0.0
>
> 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.
