Unfortunately it didn’t seem to in practice. The linked writing is about functions specifically, but excessive specialization also applies to types and Vararg. Specialization is a double edged sword: we compile more versions of a method in exchange for optimizing execution. This is worth it if we compile for a fixed number of types and reuse the compiled code in hot loops, but it backfires if we compile for an arbitrary large number of types, especially if the compiled code is not reused like in reflection. Varying over functions, Type{T}, and Vararg naturally involves an arbitrarily large number of types, and turns out their unconditional automatic specialization makes base Julia unusable.
It seems to just mean “called” but I’d want an expert on the compiler to clarify that.
That’s also vaguely worded to the point of possibly being misleading, but there’s a couple ways:
- Performance is usually hurt if the output of said higher-order function needs to be used in the rest of the code because runtime dispatches need to handle the abstractly inferred return type. But if that’s not the case, you don’t see a performance issue, in fact you may benefit from far less compilation over an arbitrarily large number of input functions. We really don’t need to compile
foo(f, x) = @noinline bar(f, baz(x))for everyfiffoois only called at top-level; we’d only need to compile thebardoing the real work of callingf. - Even in the cases where the return type should be inferred for performance, method inlining can make this moot.
mapitself doesn’t call the input function, it ends up specializing over it because of propagated inlining of the callees that do call it. This doesn’t cause compilation bloat because the inlined callees aren’t compiled separately.
Taking this into account, I view this as a weird exception that we have to live with because excessive compilation is harder to diagnose and reverse, and manually opting into nonspecialization would involve more work.