Looks like System.getProperty spends alot of time checking security:
14.44% - 4008 ms - java.lang.System.getProperty()
14.28% - 3965 ms - java.lang.SecurityManager.checkPropertyAccess()
Which would slow down the txCapsule.reUse().createXid()
-- Juha
On Tue, 31 Oct 2000, Sebastien Alborini wrote:
> 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.
>
>
