[tugu77]

This thing should be a poster example of premature optimization. Sure you can squeeze a few milliseconds out in a performance critical task. Most things won't measurably benefit though, while making all handling super awkward.

If your abstract domain description is fundamentally a collection of things that have a few parts each, then have your data type represent that, instead of turning it inside out for cache effects. If those become relevant at some point, try to abstract that away and do the optimized internal representation under the hood. But don't preemptively design your data structures in a cumbersome way just in case. That's bad advice.

[dagss]

In what context?

You are assuming the poster is doing something like your typical IO-bound backend, and not, say, a High Performance Computing simulation on a compute cluster.

I have done this kind of optimization to go from 24 hour compute time to 6 hour compute time instead for instance -- per simulation run.

How can you say "a few milliseconds" when you know absolutely nothing about the context?

I do not consider your advice any better at all; you assume all computer code is in the same context -- it really is not. Not all code is written as backend to websites.

You could have said "keep in mind that if you service is IO-bound, these kinds of optimizations are likely a waste" or similar to make the context clear.

[tugu77]

> I have done this kind of optimization to go from 24 hour compute time to 6 hour compute time instead for instance -- per simulation run.

I'm sure there are workloads where this kind of optimization makes a lot of sense. But they are comparatively rare. And they are not for free, in terms of code complexity and robustness. So, for the broad masses reading HN, its a premature optimization.

> How can you say "a few milliseconds" when you know absolutely nothing about the context?

Most code that gets written is not performance critical. Programmers would generally be better advised to think about robustness, correctness and maintainability of their code than about cache effects. The world would be a better place and we'd see fewer app crashes and fewer security holes.

[nimih]

> In what context?

This is a great question for the article's author, I think! They give very little information as to when this class of optimization makes sense, and because it's much more complex to implement than the AoS -> SoA transformation in the general case when the total ordering of enums is important, either a case-study or some general heuristics as to when this transformation is worth the effort would make the article more useful and interesting.