When you call a function f(x) it may, broadly, be the case that either the compiler knows exactly which function f is at compile time or f may be determined usi

When you call a function f(x) it may, broadly, be the case that either the compiler knows exactly which function f is at compile time or f may be determined using information such as which x is being passed in—something only known during runtime execution. Requiring that the compiler be able to determine what f is at compile time is "static dispatch" and it enables powerful compilers to work hard to vastly improve program efficiency Ahead-of-Time. Without that information, a program either has to look up which f to call every time during execution (dynamic dispatch overhead) or using a Just-in-Time compiler to optimize out this lookup when, at runtime, it has the information required to know that f is always going to be looked up the same way. Notice that this is still runtime overhead as you have to bundle a compiler alongside every program, but it's runtime overhead only once. Java is famous for this JIT behavior: expensive runtime calls have to be called enough times to pass the "burn in" period where they get optimized away and then run quickly. Languages can choose from various points on this spectrum. Lattner, the designer of Swift, is reviewing the choice he made in Swift which pairs some static features against some dynamic features. It's a fine balance to make and he claims that Swift's choice is particularly nice since it provides user-predictable performance without (a) completely eliminating all dynamic dispatch and (b) without requiring a Just-in-Time compiler.