[jdom-interest] question about running speed

[Jason Hunter]

> 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-