This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: What is executable size anyway?
- From: "Scott Gilbertson" <scottg at mantatest dot com>
- To: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- Cc: <java at gcc dot gnu dot org>
- Date: Mon, 19 Apr 2004 10:40:25 -0400
- Subject: Re: What is executable size anyway?
- References: <1082212889.4432.34.camel@famine>
Øyvind Harboe wrote:
> "Reduce executable size" comes up as a goal from time to another,
> and not only in a GCJ context.
> But what is "executable size"? What is its units?
> Here are a couple of suggestions:
> 1. seconds. How long does it take to download? Compression and bandwidth
> enters the picture here as does ease of installation. GCJ applications
> are generally less painful to install than e.g. Suns Java JRE(colateral
> damage and side-by-side installations)
> 2. harddisk space. Complicated to calculate. Rarely relevant.
> 3. in memory footprint on PC(Windows/Linux). This is related to active
> working set and hence speed of execution.
> 4. In embedded systems there might not be a virtual memory system, and
> hence every byte counts.
>
> To me, #1 and #4 are the only important ones.
5. How much code (disk and/or in-memory bytes) is inaccessible, and
therefore didn't have to be included in the statically-linked executable.
(As a percentage, maybe?)
6. How long does it take to start from (surprisingly slow) compact flash,
which is roughly proportional to #2 for a static build with no compression.
#6 is the most important one in my application (I have lots of compact flash
and ram). I gzip the (stripped) executable and unzip it to a ramdisk for
execution. This method saves about 50% on load time, because the unzip is
faster than reading the extra data.