[munificent]

> The noted efficiency in compile-time dispatch is due to decisions about function calls being made during the compilation phase. By bypassing the decision-making overhead present in runtime dispatch, programs can execute more swiftly, thus boosting performance.

The other benefit with compile-time dispatch is that when the compiler can statically determine which function is being called, it may be able to inline the called function's code directly at the callsite. That eliminates all of the function call overhead and may also enable further optimizations (dead code elimination, constant propagation, etc.).

[foobazgt]

> That eliminates all of the function call overhead and may also enable further optimizations (dead code elimination, constant propagation, etc.).

AFAIK, the speedup is almost never function call overhead. As you mention at the tail end, it's all about the compiler optimizations being able to see past the dynamic branch. Good JITs support polymorphic inlining. My (somewhat dated) experience for C++ is that PGO is the solve for this, but it's not widely used. Instead people tend to avoid dynamic dispatch altogether in performance sensitive code.

I think the more general moral of the story is to avoid all kinds of unnecessary dynamic branching in hot sections of code in any language unless you have strong/confidence your compiler/JIT is seeing through it.

[binary132]

The real performance depends on the runtime behavior of the machine as well as compiler optimizations. I thought this talk was very interesting on this subject.

https://youtu.be/i5MAXAxp_Tw

[xxpor]

OTOH, it might be a net negative in latency if you're icache limited. Depends on the access pattern among other things, of course.

[munificent]

Yup, you always have to measure.

Though my impression is that compilers tend to be fairly conservative about inlining so that don't risk the inlining being a pessimization.

[foobazgt]

My experience has been that it's rather heuristic based. It's a clear win when you can immediately see far enough in advance to know that it'll also decrease the amount of generated code. You can spot trivial cases where this is true at the point of inlining. However, if you stopped there, you'd leave a ton of optimizations on the table. Further optimization (e.g. DCE) will often drastically reduce code size from the inlining, but it's hard to predict in relationship to a specific inlining decision.

So, statistics and heuristics.

[rasalas]

In my experience it's the "force inline" directives that can make this terrible.

I had a coworker who loved "force inline". A symptom was stupidly long codegen times on MSVC.