|Looking for efficient scheme for storing structures in hashtable - com firstname.lastname@example.org (2004-10-17)|
|Re: Looking for efficient scheme for storing structures in hashtable - email@example.com (Nick Roberts) (2004-10-24)|
|From:||Nick Roberts <firstname.lastname@example.org>|
|Date:||24 Oct 2004 23:46:40 -0400|
|Posted-Date:||24 Oct 2004 23:46:40 EDT|
kevin arnold wrote:
> I am looking for an efficient scheme for storing structures, unions,
> arrays etc. in a hash table from a compiler writer's
> perspective. Maybe I should break this down into individual elements
> but not too sure. Anyone has any ideas? I would be obliged if I am
> pointed to any worthwhile reference/url etc.
The speed or memory efficiency of the storage of information such as
type structures is not normally an issue, for typical programming
languages and application areas.
Normally, the biggest problem is that of maintaining correctness: that
attributes are set and used at the right time (so that none is ever
used before it has been set to the proper value); that a modification
to the compiler doesn't cause a previously correct sequence of setting
and usage of an attribute to be disturbed; (less important) that
modification of the compiler doesn't leave large numbers of attributes
being computed and stored, but no longer used (because they have been
I feel the axiom "premature optimisation is the source of all bugs"
applies rather strongly here. Unless your requirements are unusual, I
would suggest that you concentrate first and foremost on designing
your compiler so that it is as easy as possible to: read and
understand; debug; adapt and modify. If reasonable, I even suggest
that you build- in some mechanism (if your implementation language
doesn't already provide it) to enable you to observe the state of the
attributes (of entries in the symbol table) at each stage of
compilation, so that you can either interactively debug or
retrospectively trace what's going on inside the compiler. This may
seem like a terribly inefficient approach, but I think it is likely to
Only after you have got to the point where you are satisfied with the
functionality and correctness of the compiler - and you may well find
that you need to make a lot of changes before getting to this point -
should you start to address (in detail) the question of efficiency.
Return to the
Search the comp.compilers archives again.