Publishing flamebait [Fwd: Pragmatic Bookshelf releases "FromJava To Ruby"]

Hans Fugal hans at fugal.net
Thu Jun 29 07:25:17 MDT 2006


On Wed, 28 Jun 2006 at 18:13 -0600, Bryan Sant wrote:
> On 6/28/06, Hans Fugal <hans at fugal.net> wrote:
> >On Wed, 28 Jun 2006 at 16:53 -0600, Bryan Sant wrote:
> >I'll give you that Java is fast enough once started, but startup time is
> >abysmal.
> 
> What version of Java are you running?  The 1.5 JVM starts up in 
> milliseconds.

1.5.0_4

hello world in three languages, after running a few times to get over
page faults and all that:

java: 0.120 seconds
ruby: 0.010 seconds
c:    0.002 seconds

Call me crazy, but that is not milliseconds, and that is not comparable.
It was faster than I expected though. No, I wouldn't notice a tenth of a
second in startup time, but I also didn't compare time to load up a
bunch of libraries.
 
> >And I don't care what you say, Java IS a memory hog. I don't
> >need some web article to debunk what I can see day in and day out on top
> >and ps.
> 
> That's EXACTLY the problem that the article debunks.  top and ps are
> not correctly reporting the amount of physical memory used by the java
> process.  Files that are memory mapped by the JVM (which are many --
> all the class files, the java runtime class library (40MB), etc.) show
> up as memory used by top and ps.  However these files are not
> necessarily loaded into physical memory.  ps is wrong.

ps is right, most people are simply unable to read it. It's also hard to
get the full story from ps/top. But if you know its limitations and know
what it is you're really looking at, you can still make useful
observations.

> 
> >I know how to read my top and ps output, and I know the pitfalls. I know
> >about memory mapping and shared memory and all that. It is all taken
> >into consideration in my statements above.
> 
> So, you're subtracting up to 40MB from the ps output?  Ok, well, I
> guess I stand corrected.

Sure, ok. Take your pick. Subtract 40 from one of the following:

VIRT: 406m
RES:  95m
SHR:  11m

You don't subtract from SHR, obviously. In fact you'd like that to be
higher because that means more efficiency. It would be if I were running
more java processes, I'm sure. VIRT is the part that includes all that
memory mapped stuff and whatnot. 360 is still a pretty big chunk, but
not relevant because it doesn't really affect performance.  RES is the
part of that process (including memory mapped or whatever else, and
shared) that is in physical RAM. Take off a gratuitous 40 and even an
extra 11, and you still have 45m which ties for top RAM user with
thunderbird, and they're both 20MB more than my biggest rails app. Now,
I admit it looks like openoffice isn't running...

-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach



More information about the PLUG mailing list