Not inlining but branch prediction. The switch statements of “if this unit” etc. are actually “free” when running in a loop, because your CPU does speculative execution and so it just starts executing one branch under the assumption that it’s correct and if it’s correct there’s no cost. When run in a loop, this has a process of effectively “learning” the branches to predict (internal on the CPU, some cool stuff) and so the branches predict better and the cost of having the branches is effectively zero. See:
Given this fact, I think way too many people overestimate the utility of putting this unit information into the type domain. That said, the existence of branches do cause LLVM to omit SIMD, and so if you did have a loop that SIMD’d very well you would pay the price of that being eliminated because the runtime checks would interfere with the assumptions of SIMD.
But that said, for a lot of ODE/PDE models, the main cost is in the LU-factorizations and if that just ignores units, this shouldn’t be too noticable of a hit to the f evaluations and so it shouldn’t actually show up as a major contributor in “most” profiles. You can definitely find some cases where this matters (very small cases getting very good SIMD), but I think people should really go to this technique first before trying Unitful in almost every case because Unitful is a lot more work for a performance optimization that only exists in a minority of cases (especially because many cases with Unitful will hit Array{Any} and actually be orders of magnitude slower due to dynamic dispatching).
Moral of the story, DynamicQuantities.jl is really good.