> Seems to me that using a switch over another structure for performance at the expense of readability or maintainability

But is not more readable or even more maintainable.

Plus there is absolutely no optimization involved, it's just another way of expressing it.

I was replying to a comment about the performance implications. If you decide on one method over another for performance reasons, I think it's an optimization.

> But is not more readable or even more maintainable.

Both are a matter of opinion and depend on the specific use-case.

> I'm curious how often you find yourself dealing with loops that run millions of times? I think the majority of loops I've written don't need to deal with millions of iterations

It's trivial to come up with 80s-level counter-examples to this.

A megapixel image, for example, is tiny.

It's also trivial to come up with countless "80s-level" examples that never iterate more than 100 times.

Iterating over a megapixel image isn't a common scenario unless you're processing a lot of large images. Obviously you should optimize hot code paths.

Uh, emulation and scripting language byte code engines? State machines? Filtering?

There are plenty of reasons to iterate a switch statement, even much more than millions of times.

> emulation and scripting language byte code engines

You get that these are outliers right? The majority of software doesn't need to concern itself with these problems. They're examples of software that deals with analyzing and running other software.

I'm not sure why I'm bothering to respond to these comments. This whole discussion has apparently been system developers telling app developers they need to start micro-optimizing their cold loops because "what if your user clicks the button 12 million times in under a minute".

It's actually a big issue in any performance critical regions of code. I've come across this in both the network stack and the file system (user space and kernel).

Switches can sometimes be optimised away into O(1) using clever static compile time tricks, but if you rely on jump indirection you get branch misdirection penalties, or even worse for a ladder of if's, you are doing O(N) work (where N is number of cases).

Seems like the key is "performance critical regions of code". Yeah optimize code that is performance critical. Don't optimize the other 99%.

I agree with you, yeah. The problem is sometimes you have to go back to old code and optimise it, because today's performance expectations are higher than yesterdays -- whether because hardware has become more powerful or software is being pushed to its limits. So I'm a bit biased, thinking, "If only this was optimised day 1", but truthfully, recognising the requirements and reacting to the performance needs as they arise can be less wasteful than having ironclad performance requirements that won't be met or needed to be met.

Anything with successive iterations / optimization phases, like simulation or even simple machine learning.

That's why I said "majority". Obviously you should optimize code that is run frequently. I could be wrong, but last time I checked most applications don't involve even "simple machine learning" and when they do it's in a library or service that abstracts those concerns away.

moderately sized database, pixels on a screen

Both of these seem like cases where you would know you're in a hot loop. I wasn't really clear in my comment that of course you should optimize loops that you know get run millions of times. I was saying: pick your tools based on the context of the code you're writing. Most simple applications involve tens or hundreds of loops that rarely iterate over more than a few values and don't get run more than once every few seconds.

single-page web app doing n times the amount of work it should be doing because components are synced over an event bus with bindings set up wrong in a way that nobody has bothered to debug