"Faster than Rust and C++: the PERFECT hash table"

[Christopher Katko]

> If the whole set of the string identifiers to be parsed is 
> known at compile time, then another approach for mapping them 
> to numbers or whatever else is to use something like 
> https://re2c.org

Holy crap! I was thinking about this kind of thing a few months 
ago. My situation is this:

  - I have textures (filename = string texturename) listed in a 
manfiest.json file.
  - all textures are loaded and placed into an texture[string] 
associative array
  - they're used in code that ends up being like 
drawBitmap(bitmaps["grass"], ...)

It lets me immediately add a new texture, add one line to the 
manifest, and I can call it from my code. (I could do filename = 
stringname automatically but that doesn't let me do things like 
pack textures into atlases to reduce texture swaps so that kind 
of automatic filename scanning isn't applicable.)

Noting that:
  - technically, a finite list of all potentially used texture 
names in code should be knowable to the compiler.
  - the list does not change at run time.

I had thought about trying some sort of D-based compile-time, or, 
manual tool-based lexing to build say, an enum, and replacing all 
those names from "grass01" to GRASS01=17.

But I was also wondering if simply getting a faster container 
would improve things. Because one flaw there is if I ever support 
mods, then I __do not__ at compile time know the total maximum 
set of texture name entries.

Still, once all my texture entries are received they don't change 
after loading (even if I load-in assets based on scene 
requirements, the names will never swap/reorder. Even if grass01 
texture isn't loaded, it can still have the name grass01 
reserved. There are no key deletions or changes once set. So 
grass01 could simply be a null pointer until loaded.)

Awhile back, during some profiling, D Associative Arrays were 
__way__ higher up in total CPU usage in my game than they should 
have been compared to the act of drawing entire textures. Like in 
the top 7. BUT, as I'm thinking right now, I'm wondering if now 
the profiling measuring code itself was inflating those AA 
accesses (a tiny real code compared to overhead of logging code).