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 )
addtoarray!(out.Lyy,asm[2],iele,Lyy)
end
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?