On Fri, May 24, 2002 at 10:25:34AM +0200, Pac wrote: | Le 23/05/02 à 22:09, dman a écrit: | dman> On Thu, May 23, 2002 at 07:15:34PM +0200, Pac wrote: | dman> | why ? | dman> | dman> Layers upon layers upon layers of indirection. The JVM interprets | dman> java bytecode. It then delegates the "native" methods to some C code | dman> (from the java-gnome project). Those C/C++ functions then invoke some | dman> other C/C++ functions and so on. Each has overhead. Then you have | dman> your callbacks. In Java "callbacks" are always wrapped in classes | dman> (java is not OO, it is Class-O). When you pass a callback to the | dman> java-gnome stuff it must do the necessary wrapping/unwrapping to | dman> provide a C-level function pointer to the underlying GTK+ system and | dman> marshall arguments back and forth. More overhead. The java-gnome | dman> package must also keep track of all GTK+ widgets it creates so that | dman> when the JVM's GC decides it is time to free it it can. That's more | dman> overhead in storing references. | | this is the scenario when java-gnome is not nativly compiled isn't | it ? Java-gnome is always natively compiled. You can't non-natively compile C/C++ code :-). | With a native compilation which is possible with gcc, the | application should be faster. With gcj's native compilation of java you can manage to eliminate the overhead of the JVM's main loop and bytecode interpretation. You still have all the layers upon layers of indirection and overhead that was coded from the design of the system. | dman> | the point is that evas provides hardware acceleration capabilities. | dman> | dman> Java and hardware acceleration don't mix real well. One of java's | | not exactly, for example see Gl4java which provides access to OpenGL | functions. I've tried a certain J3D app (OpenGL). It pegs my not-so-old CPU and sometimes kills the X server when exiting. I've also toyed with VPython (C++ python module providing 3D OpenGL widgets). It runs my CPU around 50-75% with an animation running. I don't remember the memory differences between the two system, and don't want to kill my X server to find out. | dman> I've worked with java enough to know that you're not going to get | dman> high-performance out of it. Swing is a dog. AWT it too limited. | dman> Everything else is less mature and adds more layers of indirection. | dman> On top of that, none of the JVMs I've used had really decent | dman> (performance-wise) garbage collectors. I haven't tried Sun's jdk 1.4 | dman> yet (is it even out of beta?) though. | | Maybe one way to tune java for high performance is a gui nativly | compiled. That may help part of it. Of course, native compilation is not a holy grail. People can write crappy C programs too. If you add enough layers of indirection and marshalling to achieve a "native" GUI you might even be worse off than just using swing. If you build the GUI directly in the JVM and can avoid many of the layers of indirection then it might help as well. For a better demonstration of the real problem with java's performance, compare javac and jikes. jikes is several orders of magnitude faster than javac and doesn't chew up nearly as much memory. Once I had to decompile a certain large library in order to tweak it a little, and then recompile it. The resultant source tree was ~15MB (no comments, no extra whitespace). Not only that, but the decompiler generated some identifiers that were legal UTF-8 encoded Unicode and totally valid in Java, but jikes couldn't handle it :-(. javac barfed with OutOfMemory exceptions (even though the system had plenty of memory left. Dumb design decision). gcj was way too slow and also barfed for some reason I don't remember (it also reported the same error many times). I managed to compile it by combining javac and 'find' in several passes. (I also learned about the MS-DOS/Windows limitations in command line length) | Sun jdk1.4.0 has been released but I've tried it and it appears to be | slower than the 1.3.1_03 for some program and take too much memory. | However Swing performances are much better says Sun's announcement... Supposedly reflection performance was greatly improved. Some benchmark showed Jython (on jdk1.4) as being faster than CPython. Jython on the other JDKs is much slower than CPython. -D -- Emacs is a nice operating system, it lacks a decent editor though GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
Attachment:
pgp510SBlq_vG.pgp
Description: PGP signature