Subject: RE: XSLT vs Omnimark From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Mon, 6 Mar 2000 11:10:52 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSLT vs Omnimark, Louis-Dominique Dube | Thread | Re: XSLT vs Omnimark, Michel CASABIANCA |
Re: Balanced Two column tables, David Carlisle | Date | re: error with xalan/LotusXSL, Paul_Dick |
Month |