Understand why `let` wrapping the compile workload can lead to worse latency

[KristofferC]

This was observed in #16. It would be good to understand the interaction with let here since ideally, it would be good to keep it.

[timholy]

I suspect it changes the interpreter/compiler heuristics in src/toplevel.c but I haven't looked in detail. And yes, ideally it would be best to be able to use let.

[adknudson]

Is this issue related to why symbols in the @setup_workload block are visible in the package namespace? I.e. if I have the following:

module MyPackage

using PrecompileTools: @setup_workload, @compile_workload

@setup_workload begin
    # these become visible in the namespace
    some_variable = rand(4, 4)
    b = rand(4)
    temp = :U

    @compile_workload begin
        some_variable * b
        some_func(temp)
    end
end

end

The variables some_variable, b, and temp are visible if a user types in MyPackage.[TAB]. I could wrap the contents of @setup_workload in a let-block and then the setup variables would no longer be in the namespace, but that feels wrong.

[timholy]

Yes, exactly. We tried to have @setup_workload do that let-wrapping for you, but it had side effects on the ordering of execution and compilation. If compilation of the workload happens before @compile_workload "tagging" gets turned on, it defeats the purpose of @compile_workload.