Hi,
Sebastien Alborini wrote:
> Here are the first results: http://www.telkel.com/optimizeit/
Nice.
It is a Good Thing to to be able to know which parts of the
system is fast and which parts are slow.
When knowing juch things, we are better suited to make good
decisions about how to do a given task.
But I wouldn't mind if you had a more detailed profile you
would like to share, even if it is big.
> For this I used jboss+embeddedtomcat, and I ran the example in
> contrib/tomcat (servlet to ejb). Only thing I changed was to use only
> optimized inVM invocations (RMI makes a lot of noise in optimizeit).
>
> Interesting parts:
> - lots of time spent in get/setContextClassLoader (security checks)
> - lots of time spent in TxCapsule.reUse
>
> Now I don't know what we can do about that, it's up to you!
On saturday I commented on the TxCapsule issue:
<Cut-n-paste>
40% of all time in TxManager.begin() is BAD !!
It is not unusual that a lot of time is spent in
the transaction manager code, but:
- This should be in commit().
- The begin() should be extremely fast, as almost
nothing is done here.
So something is extremely wrong here.
Off the top of my head comes the following possible
things that may be slow:
- My use of SoftReference for holding onto cached
TxCapsule references for reuse. In case of memory
shortage, the while loop in TxManager.begin()
could run for some time while getting references
that were cleared by the the heap manager. That
should, however, only be a one-time problem. But
maybe SoftReference is simply slow?
- The TxCapsule.reUse() method. For Oracle
interoperability Aaron recently added a more generic
way of allocating Xids. Haven't really looked into
the new TxCapsule.createXid() methods. If this is
the problem, a simple replacement of the call to
createXid() with "new XidImpl()" should make it go
away (and break the Oracle XA driver).
What situation did you profile? The load test?
Do you have a per-line breakdown of processor time
spent in TxManager.begin()?
Do you have a per-method breakdown of processor
time spent in TxCapsule?
I have thought about reusing instances of TransactionImpl
and XidImpl, but decided against it as other code may
hold on to references of these, and (with sufficient bad
luck) try to use these after they have been reused.
FastTM should not be gone. While I think a lot about
how to better interoperate with other TMs, and how
changes to our fastTM could be made to make the
implementation of this smooth, I do not think that
I have changed anything the would make it slower.
</Cut-n-paste>
<Cut-n-paste>
Just looked a little more at the changes that Aaron
committed. Looks like the zero-argument constructor
is gone.
The fact that XidImpl now uses the maximum size byte
arrays for the globalId and branchQualifier arrays
may slow down the code a little, but since the max
size is only 64 bytes this is not enough to explain
what is wrong.
The new createXid() methods may also slow down the
code a little due to the use of a java.lang.Constructor
instance for creating new Xid instances, but this
is probably also not enough to explain.
One thing could be changed to speed the code up a
little in the createXid() methods:
The first line in these methods is a call to
System.getProperty(), but the result of this is
only used if the if-expression in the next line
evaluates to true. Swapping the first two lines
in both createXid() methods may speed up the
code a little. I guess that it may also be possible
to move the Constructor initialization out of
these methods and into a class initialization
block.
</Cut-n-paste>
See how useful a more detailed profile could
be here: No guesswork, just going to cut out
slow guts and replace with faster guts.
If you have no detailed profile, that's ok.
I'll just have to work a little harder to get
this sorted out.
Best Regards,
Ole Husgaard.
