3 ms·
In old days people used #ifdef to compile things out so that the "production code" doesn't have any unnecessary branches. I was shocked when I first saw these l
by flakiness 5y ago
In old days people used #ifdef to compile things out so that the "production code" doesn't have any unnecessary branches. I was shocked when I first saw these living if()s in the server-side C++ code but then realized it was vital for debugging in production.
People also used to prefer table based jump over long if-else-if chain for anecdotal performance reasons. That has gradually changed over the evolution of CPUs with various optimizations like the branch prediction. Now some JIT impls like tracing JIT replace virtual function calls with if-elses.
By the way, I'm glad that the article is so thoughtfully written that it doesn't include any ambiguous "best practices" at the end. It could have created yet another myth. The three top tips in the article is more about stating facts. I admire the author taking that stance.
- Retric 5y agoJump tables can still be vastly faster than if-else-if though it really depends on the specifics such as the frequency of each option being correct. Best practices are always subservient to benchmarks when optimizing.
- samus 5y agoThe greatest advantage of jump tables is that they are flexible, within certain margins. You could populate them with entries from a config file or a database without having to go through a full release cycle.
- superdimwit 5y agoBig if/else lists will often get compiled into a jump table anyway.
- asveikau 5y ago> Now some JIT impls like tracing JIT replace virtual function calls with if-elses. I think it was about 2010ish when I first noticed a C compiler (Microsoft's) doing this optimization for function pointer calls. Might have been a link time optimization, because caller and callee were in different compilation units.
- Too 5y agoI think ifs based on constants get optimized to nothing anyway. So really no need to use #ifdef.