Hi,
I can expand the results, but unfortunately I can't seem to find a
per-line breakdown.
http://www.telkel.com/optimizeit/tm.html
Ask me if you want more.
Sebastien
Ole Husgaard wrote:
>
> 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.
