Re: GCJ and C/C++ applications how is it possible ?
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.
dman>
this is the scenario when java-gnome is not nativly compiled isn't it
? With a native compilation which is possible with gcc, the
application should be faster.
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.
dman>
dman> | But evas you should Xlib function create a window to put an evas
dman> | canvas into it.
dman>
dman> Ok.
dman>
dman> | I was wondering if a new GTK component were made to encapsulated the
dman> | Xlib call and be able to communicate with evas library.
dman>
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. This is possible for example with SWT which seeems mature
and provides the same functionality as Swing does.
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...
see you
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: