@mbauman dont type instabilities also account for a lot of (pre)compile time, because its more work for the compiler to resolve types?
In my experience fixing type stability absolutely reduces compile time.
1 Like
You’re absolutely right — I was wrong. As Chris notes in his magnum opus of DifferentialEquations.jl #786:
The last thing, and the major step forward, was SciML/DiffEqBase.jl#698 (comment) . As it explains, using a function barrier can cause inference to not know what functions it will need in a call, which makes Julia seem to compile a whole lot of junk . That can probably get fixed at the Base compiler level to some extent, as the example there was spending 13 seconds compiling
(::DefaultLinSolve)(::Vector{Float64}, ::Any, ::Vector{Float64}, ::Bool)junk which nobody could ever call, since any call to that function would specialize on the second argument (a matrix type) and so it should’ve been compiling(::DefaultLinSolve)(::Vector{Float64}, ::Matrix{Float64}, ::Vector{Float64}, ::Bool). But since that call was already precompiled, if inference ends up good enough that it realized it would call that instead, then bingo compile times dropped from 16 seconds to sub 3. That’s a nice showcase that the easiest way to fix compile time issues may be to fix inference issues in a package, because that can make Julia narrow down what methods it needs to compile more, and then it may have a better chance of hitting the pieces that you told it to precompile (via a using-time example in a precompile.jl).
4 Likes
Yeah thats my experience too. You can see the pyramids of compilation calls shrinking and disappearing from the flame graph as you remove unstable code. Boxed vars need much more llvm/native code than Ints and Floats.
Why do you need to convert kwargs to a Dict? Can’t that function use them as-is, or at least convert to a namedtuple (it’s type-stable)?
1 Like
The very truth is that when I started this around 2015 I was so happy to have achieved the goals of being able to easily parse multi-type inputs that didn’t look back. Since then the code grew quite a bit and now is not at all obvious to do changes. However, more recently I made experiments in parsing the kwargs directly and it made no difference in what respect the Any's side. Basically, if one want to accept multi-type inputs I think there is nothing we can do other than to try limit the Any's propagation.