This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What is executable size anyway?


Ø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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]