Hello world ;-)

#include( "windows.hhf" ); string adds up to 15 seconds to the compilation time (HLA v1.41 / Win2K / Celeron1.7GHz / 256Mb RAM)
For large projects it might not be an issue, but for simple ones (hello.exe ;-)) that's too mach.
Is there any way to speed things up (without pasting necessary parts of windows.hhf into my hello.hla)?

clone-d

P.S. regarding conversation on editors people use for *.hla - my choice is vim(and gvim).
Posted on 2003-01-25 05:00:18 by clone-d

Hello world ;-)

#include( "windows.hhf" ); string adds up to 15 seconds to the compilation time (HLA v1.41 / Win2K / Celeron1.7GHz / 256Mb RAM)
For large projects it might not be an issue, but for simple ones (hello.exe ;-)) that's too mach.
Is there any way to speed things up (without pasting necessary parts of windows.hhf into my hello.hla)?

clone-d

P.S. regarding conversation on editors people use for *.hla - my choice is vim(and gvim).


The answer to you question is yes, there is a way for
me to speed things up -- finish HLA v2.0!

The truth is, I *did* speed it up quite a bit. A few versions
back when I first put together the windows.hhf header file
a trivial program that included windows.hhf was taking
45 seconds to compile (on my 300 MHz PII). I rewrote the
symbol table search routines for namespaces to use a
hash table rather than a linear search, and the compilation
time was reduced to about 23 seconds (17 seconds on my
2.0 GHz PIV at work; interesting that a CPU running over
six times faster posts such a small improvement in performance).

HLA's symbol table routines heavily depend upon the linear
search algorithm I implemented way back in v1.0. After studying
the problem for a while and trying to figure out a way to do
a binary search, I came to the conclusion that it was a lost cause
and it would be better to save the effort for HLA v2.0. As I mentioned,
I did kludge in a hash table lookup for namespaces that sped up
access to symbols found in a namespace, but this improvement is
only realized when accessing a namespace object from outside the
namespace. While actually building the namespace in the first place,
HLA still uses a linear search. So moving all the Windows declarations
into the "w" namespace improves access from your source code, but
doesn't help a whole lot while building the symbol table for "w" in
the first place. Most of the performance improvement in HLA's
symbol table lookup (roughly 2x) was achieved by rewriting some
critical code in assembly language rather than C.

I certainly feel for you. I'm going through some of the same pain
on some of my own projects. For most projects that are going to
involve a lot of iterative edit-compile-run cycles, I just copy the symbols
to a "w" namespace in my own header file. For "one-off" type projects,
I bite the bullet and spend the 22 seconds compiling everything.

The symbol table in HLA v2.0 has been specifically designed to
overcome this problem (it uses a combination of hash table and binary
search to speed things up). Alas, retrofitting this to v1.x requires
a complete rework of the entire compiler and is, therefore, out of the
question.
Randy Hyde
Posted on 2003-01-25 11:35:51 by rhyde