openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christiaan (JIRA)" <>
Subject [jira] Commented: (OPENJPA-439) Performance degradation in multi-transaction operations
Date Mon, 12 Nov 2007 10:55:51 GMT


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:
>             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,
> 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
> Discussion:

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

View raw message