On 3/2/07, Elliotte Harold <elharo@m...> wrote:
> Rick Marshall wrote:
>
> > The implication is that Java can create a sequence of instructions that
> > C can't.
>
> Essentially it can. Runtime (JIT) optimizers know things static
> optimizers don't. They can sometimes tell that a particular code path
> will not be taken or that an object has a certain type or other useful
> information that is simply not known to the static, compile-time
> optimizer. They can sometimes use such information to run even more quickly.
>
> The nature of the languages also plays a part. Pointer aliasing is a big
> problem for C and C++ optimizers. It's a reason Fortran outperforms C,
> even with the same compiler. Java doesn't have C-style pointers so it's
> more like Fortran in that regard.
>
> And of course manual memory allocation is almost always slower and less
> reliable than a good garbage collection library. You can use a garbage
> collection library for C/C++, but few programmers do in practice.
>
> Together these are enough to push Java a couple of percentage points
> ahead of C on some problems. Not all problems, certainly, but enough of
> them that you can't just naively assert that C must be faster than Java.
>   That may have been true in 1997. Today it demonstrably isn't.

Except that we are talking about the performance of XML parsers, and
XML is all about string processing and Java string processing is slow.
 Java XML parsing will never be faster than a good XML parser written
in C.  There is just too much overhead, and C benefits from 'struct's,
the lack of which hinders ones ability to write certain constructs
efficiently in Java.    Any sufficiently fast Java XML parser could be
ported to C and made faster in the process.

Unfortunately, your application would also have to be in C, because
the interop cost for passing strings from C to Java is huge, and the
overall development benefits of developing (most) apps in Java/C#/etc
far outweighs the performance loss.

-derek