[
https://issues.apache.org/jira/browse/OPENJPA-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541738
]
Christiaan commented on OPENJPA-439:
------------------------------------
I did a rerun of the testcase with the provided patch (I had to some changes to
the query since Kodo 4.1.4 results in an exception with this openjpa version).
The results are great:
Collecting 41371 objects took: 0:0:12:61 (12061.0 ms)
Deleting objects took: 0:0:6:356 (6356.0 ms)
duration 1st run: 0:0:18:417 (18417.0 ms)
Collecting 41371 objects took: 0:0:10:713 (10713.0 ms)
Deleting objects took: 0:0:5:751 (5751.0 ms)
duration 2nd run: 0:0:16:464 (16464.0 ms)
As you can see the collecting of objects in the second run has now been reduced
from 22 seconds to 10 seconds (see output in previous comment), which is even
faster than the first run! The hotspots for the first and second run are now
the same and the top 10 hotspots are java. methods (the first openjpa hotspot
is org.apache.openjpa.jdbc.sql.SelectImpl.getTableIndex which has only 0,3%
self time). I also had a look at the memory usage since as mentioned the second
run had a 15 mb increase of memory compared to the first run. This 15 mb
increase of memory is now solved as well, so the second run has the same memory
pattern has the first run.
There is still one question pending. As mentioned, once all objects to be
deleted into memory (40 mb) performing pm.deleteAll() increases the memory with
another 45 mb. Is this as expected or should this be investigated as well?
> Performance degradation in multi-transaction operations
> -------------------------------------------------------
>
> Key: OPENJPA-439
> URL: https://issues.apache.org/jira/browse/OPENJPA-439
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0, 1.0.1, 1.0.2, 1.1.0
> Reporter: Patrick Linskey
> Fix For: 1.1.0
>
> Attachments: OPENJPA-439-patch.jar, OPENJPA-439.patch, performance
> testcase results.zip, testcaseperformance.zip
>
>
> Reusing a Broker for multiple transactions / persistence contexts
> demonstrates a performance degradation, possibly due to explicit calls to
> clear sets and maps, rather than just dereferencing them.
> Discussion:
> http://www.nabble.com/Performance-drop-in-AbstractHashedMap.clear%28%29-tf4769771.html#a13656730
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
