Publishing flamebait [Fwd: Pragmatic Bookshelf releases "FromJava To Ruby"]
ross at indessed.com
Thu Jun 29 10:30:36 MDT 2006
On Thu, 29 Jun 2006, Hans Fugal wrote:
>> I'd have to agree that Java is typically more memory-hungry than other
>> applications--however, in my experience that's only a one-time cost. In
> Half a Gig!!! Even emacs can't approach that.
Yeah, but Open Office can, and it's more similar in terms of the
functionality it provides. Pretty UIs are very expensive in terms of
memory, and emacs and vi avoid that cost. But that's why I say Eclipse
makes for a crappy text editor--for much the same reasons why Open Office
makes for a crappy text editor.
>> little overhead above that, as well as half a dozen other Java apps. The
>> intial memory cost to have something running in a JVM seems to be rather
>> high, but once you hit that point everything else seems to be very
>> comparable to non-Java applications in terms of memory usage.
> The same is true of gnome and qt/kde, the ruby interpreter, rails (if
> you're not using a frozen copy in vendor/), php, apache, etc. It's the
> beauty of shared memory.
Exactly my point. When you're using most other (non-Java) programs, you
get a memory "bonus" of some typical low-level libraries (at least glibc)
already being available in memory. Java programs start from scratch (more
or less), so it's only expected that they'd have a greater overhead for
What really interests me is the idea of a Java operating system created
in Java from the ground up. Like, for example, jnode
(http://www.jnode.org/node/132). It seems to me that in such an
environment Java applications would have a similar memory footprint and
similar speed as similar non-Java applications running on a "normal"
operating system, since the JVM and common libraries would always be
running and in memory.
More information about the PLUG