Re-2: [ObjectWeb architecture] just an idea for (Java) native comp ilation

[<markus.karg@xxxxxxxxx>]

Dmitry,

thank you for that explanation. So this means, the more complex the 
application is, the larger the EXE gets. Maybe beyond the original size of 
the APP, since you need to pack the APIs into the EXE.

Have Fun
Markus

-------- Original Message --------
Subject: RE: [ObjectWeb architecture] just an idea for (Java)  native comp  
ilation (07-Okt-2003 9:27)
From:    dleskov@xxxxxxxxxxxxxxxxx
To:      markus.karg@xxxxxxxxx

> > >   There are a few other issues when native compilation can make a
> > > difference, such as the download size of a self-contained package. Have
> > a
> > > look at http://www.excelsior-usa.com/jetbenchsize.html - download sizes
> > > start from as little as 0.34 MB ("Hello, world" JetPerfected against JRE
> > > 1.3.1 and zipped.) 
> > 
> > from your experience, does that factor scale linear with application size
> > or is that difference in "Hello World" bound to some static offset? I
> > mean, maybe with large applications that offset will not be the problem as
> > its influence will shrink compared to the influence of the linear code
> > size.
> > 
>       First of all, the size factor depends not exclusively on the
> application's size but on which subest of the platform APIs it uses. The
> Java 2 API classes reference each other in a spaghetti fashion, and the
> situation becomes worse with each J2SE release. On JRE 1.4.2, even the
> minimal "Hello, world" sample involves 696 (!) classes from rt.jar, of 
> which
> 248 are actually loaded - just run "java -verbose hello". The global
> optimizer of course removes unused methods, inserts stubs instead of 
> classes
> that are imported but never instantiated, and so on, otherwise the 
> resulting
> EXE would have been much larger.
> 
>       Then, the classes that constitute the Swing and AWT APIs are very
> tightly coupled, and there are many of them. As a result, an executable for
> even the smallest GUI app would have a size of several megabytes, whereas a
> large non-GUI program concentrated on something like XML transformation may
> compile to a smaller executable. The use of SWT also helps in that regard.
> 
>       We also have the internationalization issue. If you need your
> compiled application to support all locales and encodings supported by the
> respective JRE, you have to include all the locale classes and all classes
> from charsets.jar, some of which, such as Japanese or /Chinese/Korean
> contain very large tables 
> 
>       To summarize (and to answer your question), the factor scales linear
> if we define "application size" as "the total size of application's classes
> plus all required classes from the JRE". So the global optimization 
> benefits
> for a large application are likely to be limited to performance.
> 
> 
> 
> To: markus.karg@xxxxxxxxx
>     architecture@xxxxxxxxxxxxx