[4221] in java-interest
Re: Optimized Future Performance of Java (bleak?)
daemon@ATHENA.MIT.EDU (Steve Naroff)
Wed Dec 13 18:42:11 1995
From: Steve Naroff <Steve_Naroff@next.com>
Date: Wed, 13 Dec 95 16:07:18 -0500
To: "Jeremy Fitzhardinge" <jeremy@suede.sw.oz.au>
Cc: Kelvin Nilsen <kelvin@kickapoo.catd.iastate.edu>,
java-porting@java.sun.com, java-interest@java.sun.com
Jeremy> The biggest Java program I know of, Hotjava, certainly has
performance comparable to netscape, even with the interpreted
runtime. Javac, on the other hand, is pretty slow, probably because
its more CPU bound (and IO bound, which isn't going to be helped by
a faster runtime).I expect that a given Java program will use
50-100% more memory than a C one with no memory leaks.
Hotjava is long lived and javac is short lived. I believe this
contributes to the perceived difference in performance. For example,
running the compiler causes more than 400k to be "malloced". This
is basically the cost to "interpret" the symbol table within the
.class files (which are loaded to do the compilation). Since the
current compiler is batch oriented, you pay this price everytime you
compile.
To make matters worse (for javac), its import mechanism also
depends on "interpreting" the symbol table. For example, highly
composed classes (like Parser.java) compile MUCH slower that
reasonably atomic classes (like String.java). Here are some number
you might find interesting (for compiling "helloworld.java"):
9844 bytes for class structures (107 classes...92 bytes each)
15648 bytes for field structures (652 fields...24 bytes each)
72320 bytes for method blocks (1130 methods...64 bytes each)
19729 bytes for method tables (per-class method caches)
69928 bytes for method instructions
736 bytes for exception frames
71590 bytes for constant pool vectors (14318 elements)
147446 bytes for constant pool (where all names and types are stored)
7752 bytes for name/type hash table, (1373 elements)
These numbers were obtained with Sun's VM. Obviously, a Java
compatible VM may be able to improve on this. Notice that the
absolute number of class/field/methods is not very large. Its fair
to say that "launching" a medium-large app from just .class files is
going to be slow. For code that isn't "moving", its easy to imagine
a post processor that improves on this...we have been doing this in
Objective-C for years (it helps quite a bit).
I believe 50-100% more memory than C is very optimistic...maybe you
weren't considering the symbol table overhead.
Thanks for the thoughtful response (to Kelvin's email), I enjoyed
reading it...I've reached my saturation point with "industry babble"
on comp.lang.java.
snaroff.
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
