RE: XSLT vs Omnimark

Hi Louis-Dominique

Louis-Dominique said:
Or they will compile Java to native binary code.  A lot of work is
done on JIT-compiling.  Of course, the problem with JIT... if it is
really JIT... is that your startup time may be significant.  The work
there could be taken one step further though and have the whole thing
cached or just plain compiled like C++ is.  (I'm not saying that there
are not caveats or that this is simple: just that this is possible.)

Didier replies:
Yes a lot of things are feasible but a reality remains: the Actual Java is
slooooow even with the newest Hot spot technology. I am still amazed why
something as simple as the following is not yet implemented (may be too
simple I guess :-))

a) the byte code is downloaded
b) it is compiled into native code locally
c) it is then stored in a cache (this would imply that each class would be
properly classified in a particular namespace to prevent name collision).

The first time you run the apps, you would have the overhead of the
compiling but after this time,

a) when the class is called, its binary version is running

What is the difference between this an JIT? Simple, it is compiled only once
and cached for future use. It means that we would have about the same thing
as we get with today's desktop apps but the code transportation would be
simplified. In fact, it means that the byte code would be used only to
transport the code and this latter to be compiled into native code. Only
native code would be running.

We will still have some overhead with the code written in C++. Garbage
collection is one, function or class member call is an other.

Actually the advantage of Java compared c++ is more for the developers than
for the users. I can see one advantage to the users thought, a potential for
less memory leaks with Java. Memory leaks is still the Number one weakness
of C++ but speed is still its biggest quality.

If we want to get an XSLT engine able to sustain thousands of users, With
C++ we can pretend to have a better usage of the hardware resources but have
also the risk of a badly developed interpreter with memory leaks. With Java,
no memory leaks but with thousand users, frequent garbage collection (and
inconsistent behavior) also, a slower XSLT interpreter.

So yes everything is possible but it remains that today XSLT engines written
in Java are still slow. This is the reality we have to face and I hope that
we will have a fast and reliable XSLT engine available. If only Java would
be made more efficient...

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@xxxxxxxxxxxxx
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list