Help with 64-bit arch for compiling large program?

Jason Holt jason at
Sat Mar 11 22:16:28 MST 2006

On Sat, 11 Mar 2006, Levi Pearson wrote:
> Dude.  WTF.  When they said 'Premature optimization is the root of all evil', 
> they must have just recovered from a vision of this particular code.
> If I were hiring someone, and got this as a serious submission, the resume 
> would be immediately dropped in the circular file.

I dunno; I consider it a reasonable abuse of the rules, since he just 
specified fastest runtime.  It's actually a straightforward solution to the 
problem of finding a maximally fast hash lookup -- gperf is the traditional 
tool for such things, and it was simple to modify its output to keep an 
accumulator for each entry.  The fact that it took many hours to generate a 
perfect hash and resulted in a 64MB .c file is just a weakness of the tool 
when applied to a dictionary with 100,000 entries.

The .c file could actually be much smaller, but I allowed gperf to create a 
table up to 10x the input keyspace, since that seemed to make it run fastest 
for my smaller test runs.

> P.S. It might help (once you get past the fact that it's too big to compile) 
> if your array of strings actually had more words than "thoroughbred" in it.

Not true.  "wristband", "bagged" and "cresting" are there, along with 
everything else in /usr/share/dict/words.  It's just a rather sparse table.


More information about the PLUG mailing list