[jdom-interest] question about running speed
dms at sosnoski.com
Wed Apr 10 01:38:01 PDT 2002
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.
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
>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.
More information about the jdom-interest