[
https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471761
]
Kevin Sutter commented on OPENJPA-138:
--------------------------------------
I was waiting for Abe to weigh in... :-)
> o Cache the Type hashcodes for OpenJPAId.hashcode()
> Already being done as far as I can tell, unless you mean a static
> Class->hashcode map, in which case -1.
Yes, I am using a static ConcurrentReferenceHashMap to store the hashcodes.
Why the -1 with this change?
> o Cache the Type's ClassLoader instances in ObjectValue.newInstance()
> I have a hard time believing that Class.getClassLoader() for the few things
> that we dynamically create more than once > via ObjectValues is a significant
> performance problem.
The caching definitely seems to have helped. More information at end of this
append.
> o Cache the assignable "from" types and associated value "to" types in
> FetchConfigurationImpl.isAssignable
> Again, I have a hard time believing this is significant. What JVM is this
> that methods on Class seem to be so
> ridiculously slow, to the point that you want to create and maintain Maps of
> Maps to work around it?
:-) Not sure if it's due to the IBM JDK or not, but the Class.isAssignableFrom
method is very CPU intensive.
Patrick earlier indicted that "numbers don't lie". We've been running an
internal benchmark using OpenJPA (and other JPA vendors). Our performance
numbers more than doubled just with the changes listed in this Issue (minus the
Broker pooling and the Configurations.newInstance caching). Can't give any
more details at this time. You'll have to trust me. :-)
Thanks,
Kevin
> More performance improvements for OpenJPA (lib and kernel)
> ----------------------------------------------------------
>
> Key: OPENJPA-138
> URL: https://issues.apache.org/jira/browse/OPENJPA-138
> Project: OpenJPA
> Issue Type: Sub-task
> Components: kernel, lib
> Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> As we continue pushing OpenJPA though its paces, we're finding a few
> additional tweaks that help with the performance throughput. This Issue will
> be used to track this next set of improvements. I'll document more detail as
> we determine the correct fixes. Several of the changes relate to caching of
> objects in a hashmap instead of re-creating the objects every time we call
> some of these methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
