[jdom-interest] question about running speed

[Dennis Sosnoski]

I've been using JDK 1.3.1 for my testing, though I should probably move 
to 1.4 soon. It'd be interesting to compare times with the IBM JVMs as 
well. A lot of the current performance anomalies are due to Hot Spot, 
which goes through a lot of work to handle short lived memory 
allocations well but from what I've seen does not optimize 
computationally-intensive code as well as the older JITs. IBM's approach 
was more traditional, last time I checked. For real-life applications 
where performance is an issue developers should try both and see which 
gives best results.

As for walk time vs build time, unless you're making a lot of passes 
through the tree build time is going to be much more important - it's 
generally about 10-20 times larger than walk time. If the build process 
can bypass the validation checking as discussed in some recent emails 
this may help.

Shinnie, from your symptoms I think you should definitely try increasing 
the memory as I suggested in my first response. If you're running out of 
memory now it can cause performance to drop to a crawl.

  - Dennis

Jason Hunter wrote:

>>You mean that it is true that beta8 is slower than beta7?
>>ok. I just want to make it clear.
>>Thank you very much.
>>
>
>It's really hard to make that comparison.  Walking the tree may be twice
>as fast while building the tree may be 20% slower.  So which is faster? 
>Depends on your use case.  It also depends on your JVM (JIT or HotSpot),
>your JDK version (because StringBuffer isn't implemented the same
>everywhere), the memory you allocate (speed's easy to get if you
>sacrifice memory), and more.
>
>Across all languages it's hard to do performance testing of programs. 
>With Java it's extra difficult because the things that most impact
>performance are out of your control.  I found one program I was working
>on (not JDOM related) ran 250% faster with JDK 1.4 than with JDK 1.2. 
>Same program, faster run.  Other programs on JDK 1.4 see no change.  So
>imagine if my program and a competitor program were of equal speed on
>JDK 1.2.  Can I now claim my program's 250% faster?  People who run JDK
>1.2 won't think so.
>
>This hit Xerces actually since it was tuned for JDK 1.1.x and when JDK
>1.2 came out it ran slower while other programs that weren't so heavily
>tuned ran faster.  Too much tuning for a particular environment in Java
>causes problems when you're not in that environment.
>
>The main point is, to know how your app is going to perform, you need to
>run your app and you need to run it on the production system or one like
>it.
>
>As for us, we'll be trying to fix the StringBuffer.copy() bottleneck we
>see in JDK 1.2, but it looks like JDK 1.4 may not share the same
>underlying implementation, so for JDK 1.4 users this work won't matter
>at all.  Who knows about non-JDK execution.  Oh the fun.
>
>-jh-
>