In August Productions

A couple of days ago, while fighting with removing warnings from the Sun Studio build of Drizzle, I got frustrated and took a break to tackle one of the little things I've been wanting to do for a while.

Delete gen_lex_hash

(Just in case gen_lex_hash means nothing to you, it's a tool in the MySQL and Drizzle source tree that creates hash structures containing the reserved symbols for easy lookup during parsing)

Now, don't get me wrong. It's not that I have anything in particular against the code in gen_lex_hash. It's more of an annoyance about building and using a custom code-generation tool when there is a perfectly good general purpose one out there in the Free Software universe.

I replaced gen_lex_hash with gperf, which is a GNU tool for generating perfect hashes. There are several wins here:

1. We have no more tools that must be built to generate code which is then built as part of the source, making the build process easier to grok. We removed comp_err early on in favor of some header files and gettext.
2. Code that writes code is usually rather obtuse to get in to. Tweaking said code is often times even more odd, and often times people just don't do it. gperf has commandline configuration options to control various qualities of the generated hashes, so we can easily play with optimizing the hashes.
3. The code for looking something up in the generated hash has a clean API, and the method that actually does this went down from a couple of pages to 3 lines. WIN
4. Advances in the field can be incorporated into gperf upstream and we can take advantage of them.
5. The build system has gperf as part of the process now, so if someone wants to pre-generate any more hash structures, the tool is already plugged in and there is an example of its use. Before, gen_lex_hash would have had to have been patched to support generating another hash, so it really wasn't a sensible option.
6. We no longer have weird defines protecting part of a header from being sucked in when it was used for gen_lex_hash, but not in other times.

All in all, I think it's a win. It's also not a hard patch to make, it turns out. I've already mailed it over to the MySQL build team to look at.

It will be interesting to see if there are any perceivable end-user benefits in speed. I'm guessing probably not, but you never know.