So, how long does it take to identify a verb on a 2.66GHz Core2 MacBook Pro…

  FOURCC                         4.9ns   // The parent comment code
  FOURCC-without-alignment-bug   6.1ns   // ... safely assemble the word
  NGINX                         10.3ns   // main ariticle's code
  STRCMP                        17.6ns   // most commen verbs first

The FOURCC codes as in the parent only work if you can assume you know the character after the verb to be a space or other known character because GET and PUT are too short. They also require disambiguating code for the 5+ letter verbs but these are all relatively rare (probably).

My strings are all 4 byte aligned, so the FOURCC case may be getting an unfair boost, it never generates an unaligned read which possibly is slower.

Test data is a set of jumbled GET,HEAD,POST,PUT lookups that I made up to meet my idea of a web server.

There are some worst cases hiding out there, for instance all PROPPATCH verbs…

  FOURCC                        14.7ns
  FOURCC-without-alignment-bug  17.7ns
  NGINX                         19.8ns
  STRCMP                        37.4ns

Feels like gcc sequentially tests case values. Make sure to put them in the order for common verbs to match first. The FOURCC codes get the most control here. NGINX is most consistent, probably from its two layered lookup nature.

So there you have it: nginx's algorithm is significantly better then strcmp, and fairly independent of verb distribution. A FOURCC lookup is faster, even if made safe for all architectures. And finally, strcmp isn't that bad (freebsd anyway, the GNU libc is about half as fast as seen in further testing).

(I am left with a nagging desire to check a perfect hashing function though.)

Edit: gperf is about 50% slower than the nginx method. No need to go that direction for perfect hashing.