RE: native sablecc.exe

["Erik Poupaert" <erik.poupaert@chello.be>]

>>>> How is the speed performance of your executable vs. running the
classfiles on a modern VM?

I don't think you will see any difference visually while the application is
running. Startup, however, is of course faster; not really with SableCc,
because SableCc has its own startup obligations.

To figure out exactly, I would have to benchmark against a set of
representative grammar files. Furthermore, I've built the executable
optimized for size (-Os) and not for performance.

As a matter of fact, the GCJ compiler, at this stage, does not implement the
most obvious Java-oriented performance optimizations possible. I was, for
example, thinking of maximally allocating to the stack, instead of the heap,
and in such way avoid garbage production and collection. That requires call
graph analysis, however, and I'm afraid we won't get that any time soon; all
of this, of course, without breaking Hans Boehm's garbage collector's
assumptions. If such optimization changes the lifetime properties of the
residual garbage (to be collected anyway), these optimizations may very well
defeat the object.

As soon as the sources cross the notorious GCC backend "fence", and becomes
a indistiguishable GCC ASTs (as described in tree.h, I believe), they will
start benefitting from the well-known and ordinary optimizations available
in GCC. I understand that there are numerous trade-offs involved there; of
which I don't know all implications. I am, unfortunately, not a GCC exegete.
I've actually just started using it 2 weeks ago.

Another issue that affects performance, is the fact that gcjlib/ClassPath
sits on top of JNI, instead of taking a shorter route. I am not really happy
with this choice, but the GCJ/ClassPath maintainers fervently believe in the
approach, as I have understood, regardless of performance.

I don't really see a native executable as a way to gain performance, but as
a way to avoid distributing huge runtimes. And as a way to distribute
self-contained executables with all dependencies included. I'm a great fan
of linking statically, because it simplifies distribution (one, single
file), installation (zero installation), and much easier support (no
stochastic environment or dll hell):

 "double-click and go!"