Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
KristofferC opened this issue May 8, 2023 · 2 comments

Comments

@KristofferC
Copy link
Sponsor Member

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
Copy link
Sponsor Member

timholy commented May 8, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants