The only reason that you'd want to optimize this function is if it's called frequently. Imagine you you have a text file or database with millions of numbers in ASCII hexadecimal notation. When parsing that data with this code, the table is practically guaranteed to be in the cache.

Modern processors have 32 KB in L1 just 4 cycles away, hundreds of kB in L2 12 cycles away, and MB of L3 on-die cache which still only takes 50 cycles or so. I'd trust the machine to be certain to put this 256 byte table in L1. It would probably even pull the relevant parts (48-57 for the decimal digits and 65-70 for alphabetic) of a 65 KB 2-entry table if you were calling it in a tight loop. I'm curious if you could load it fast enough to sort out cache when working with a 4-entry, 4 GB table...