[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE / CORBA / C++ a historical viewpoint
From:       Bavo De Ridder <bavo.deridder () cs ! kuleuven ! ac ! be>
Date:       1999-09-17 17:20:00
[Download RAW message or body]

On Fri, 17 Sep 1999, Jo Dillon wrote:
>Bavo De Ridder (bavo.deridder@cs.kuleuven.ac.be) spake thusly:
>> Not when using native compiled Java.
>
>  That isn't a magic bullet. Compiled languages can be inefficient, and
>given Java's admittedly-groovy dynamic method invocation, compiled java
>is likely to be.
>
>-- 

Hmm, this is actually one of the points where Java is faster than C++ ....

C++ has mixed dynamic/static method invocation. Java only has dynamic method
invocation. If you have lot's of virtual functions in C++ (see Qt ...) than
Java will actually be faster than C++ ....

BTW (1): GCJ is a mixed compiled/interpreted system. The best of both worlds.

BTW (2): machinelanguage is faster than C which is faster than C++ ... you
always pay a price. However, I think a full blown KDE 2/3 in C++ + CORBA will
actually be slower and use more memory than KDE written in Java and compiled
with gcj.

My experience show that a non-gui Java program is as fast as a C++ program, the
memory usage is comparable (not counting the overhead of the VM which is static
and won't grow when the program grows). For instance: alllocating 1000
javax.mail.MailMessage's (this is not the exact name, but you now what kind of
class I mean; I actually tested this once), gave a memory increase of 150-200
Kb. Those MailMessage objects included configuration file support, multipart
messages, dynamicly pluggable backend (Internet, Lotus Notes, ....). 

A GUI  program is slow because the bytecode is interpreted. Compiled code
should improve dramatically on that.


BDR

[prev in list] [next in list] [prev in thread] [next in thread]