Long compilation time of own code

I am getting a very long TTFX on my own code. This is new territory for me. I profiled the compilation and first run, and the profiler reports large amounts of time spent on the call value_∂{1,Ny}(...) (which does perfectly fine in other settings), and I start throwing hypotheses around (see below).

function addin!(out::OUTstaticΛXU,asm,iele,scale,eleobj::E,Λ,X,U,A, t,γ,dbg) where{E}
    # compile-time stuff (I hope)
    Nx,Nu           = getndof(E,:X),getndof(E,:U)
    Ny              = 2Nx+Nu                           # Y=[Λ;X;U]   ments...    
    ΔY              = variate{2,Ny}(δ{1,Ny,𝕣}())                 
    iλ              =           SVector{nX}(1:nX)
    ix              = nX      .+SVector{nX}(1:nX)
    iu              = nX+nX   .+SVector{nU}(1:nU) 
    ΔΛ,ΔX,ΔU        = view(ΔY,iλ),view(ΔY,ix),view(ΔY,iu)
    # run-time stuff
    L               = scaledlagrangian(scale,eleobj, Λ+ΔΛ, (∂0(X)+ΔX,),(∂0(U)+ΔU,),A, t,γ,dbg)
    Ly,Lyy          = value_∂{1,Ny}(∂{2,Ny}(L)) 
    addtoarray!(out.Ly ,asm[1],iele,Ly )

Hypothesis 1: This is because of something unclear with types which gives the compiler a hard time to generate typestable code. By design all the code in the first half of the function should evaluate at compile time. Note how Nx and Ne are function of type E, and everything else down to ΔΛ,ΔX,ΔU is computed from these values. But is this code actualy evaluated at compile time? Is this evaluation hard on the compiler? Should I be using a @generated function to explicitly require this computation to be done once and for all?

Hypothesis 2: I known that scaledlagrangian calls some type unstable code. I know how to fix this, but I wonder, is there any way type instability can make compiling harder?

Question: where can I read up on the strategies to profile the compilation process?

Question: I tried to use @code_warntype on this function. Because its hard to generate all the inputs for the function, I would prefer to do this inside the calling program, not from the REPL. Of course the macro’s full name InteractiveUtils.@code_warntype gave me a warning of what was to come. Is there any way around this?

Check by calling your function with @code_typed and see if you find Core.Const in the lines for which you expect compile time evaluation.

1 Like

How large are nX, nU and other sizes of these SVectors? SVectors with large sizes (> ~50) take a long time to compile (and are not recommended in general).

They are small. Actual 2 to 4 in the case that gives me looong compilation.

1 Like

Great tip! I will work on this.

…and I think you are spot on, @Imiq. The compiler seems to choke on Ny = 14, and I have a 14x14 SMatrix

Thanks a bunch, and I take note of @fattenedders tip on @code_type.

Thank you both!

1 Like