Optimal way to create a static lookup table?

[Karl]

@Joe_Groff

Moving your lookup table array from a local variable to a global/static let should get the object initialization overhead out of your function and into a one-time initializer, at least.

Oh, that's much better! I guess I just saw the retain/release calls and assumed it was due to using an Array, so I immediately switched to a tuple instead. That's also why I added a 99 as UInt8 element at the end (the idea was that if I didn't explicitly ask for an Array, the compiler might be able to see that I only want to subscript in to the array-literal and might be free to make something more optimal than a true Swift Array - just a wild punt).

Is there a reason the optimiser can't automatically turn non-trivial constant locals in to globals?

---

@eskimo

I’m leary of this technique. While it was definitely valuable on the 6502, modern CPUs tend to be fast at computation and slow at I/O [1].

Have you thought about doing this using SIMD ? There will be more instructions in your loop but each iteration will process more results.

That's certainly true. I was trying to go for a sort of middle-ground: having the lookup table only handle the interesting part to reduce code size and cache pressure, and bounds-check to the table region as a compromise. It's possible that by using both approaches I actually end up with the benefits of neither.

SIMD is a really great idea. This is actually supposed to be part of a parser for IPv6 addresses, so I think that would suit SIMD really well. I never thought of using that - thanks a lot!