I agree with the following quote, I think that was not
followed in the past: Optimizations that may have a large negative impact to
usability may ->need to be only enabled through specific configuration<-.
It's not clear that the optimizations listed are driven by
profiling real application. EclipseLink still generate duplicate select, extra
flushes, and other unwanted trip to DB. Also support for query in memory is
minimal so we have to call DB more often than needed. So by comparison, micro
optimization may easily be orders of magnitude less important on the response
time.
From CPU point of view, it is clear for us, under
consistent, documented load testing, that the bottleneck is a Sun JVM API,
which could and should be avoided -> java.lang.Class.isArray(Native Method);
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=288864
From:
eclipselink-dev-bounces@xxxxxxxxxxx
[mailto:eclipselink-dev-bounces@xxxxxxxxxxx] On Behalf Of James
Sutherland
Sent: Wednesday, January 06, 2010 3:42 PM
To: Eclipselink-Dev@Eclipse. Org (E-mail)
Subject: [eclipselink-dev] 2.1 design doc added for performance
andconcurrency
2.1
design doc added for performance and concurrency
http://wiki.eclipse.org/EclipseLink/DesignDocs/298985