-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
unnecessary boxing of variables that are not reassigned within a closure #56561
Comments
/cc @JeffBezanson Could I hear your thought on this? I'm sorry if this is a known issue. |
I think the challenge is that lowering needs to prove that no re-assignments occur after closure creation, because if any do, then the closure's captured variable needs to be able to be changed. Ref #15276 (comment) Functions called with the julia> function demo_box(a)
x = sin(a)
f = identity() do a
a + x
end
@show f(1)
x = 123123
@show f(1)
end
demo_box (generic function with 1 method)
julia> demo_box(1.23)
f(1) = 1.9424888019316975
f(1) = 123124 |
Performance issues related to code containing closures are frequently discussed (e.g., #15276, #56561). Several approaches can be considered to address this problem, one of which involves re-inferring code containing closures (#56687). To implement this idea, it is necessary to determine whether a given piece of code includes a closure. However, there is currently no explicit mechanism for making this determination (although there are some code that checks whether the function name contains `"#"` for this purpose, but this is an ad hoc solution). To address this, this commit lays the foundation for future optimizations targeting closures by defining closure functions as a subtype of the new type `Core.Closure <: Function`. This change allows the optimizer to apply targeted optimizations to code containing calls to functions that are subtype of `Core.Closure`.
Performance issues related to code containing closures are frequently discussed (e.g., #15276, #56561). Several approaches can be considered to address this problem, one of which involves re-inferring code containing closures (#56687). To implement this idea, it is necessary to determine whether a given piece of code includes a closure. However, there is currently no explicit mechanism for making this determination (although there are some code that checks whether the function name contains `"#"` for this purpose, but this is an ad hoc solution). To address this, this commit lays the foundation for future optimizations targeting closures by defining closure functions as a subtype of the new type `Core.Closure <: Function`. This change allows the optimizer to apply targeted optimizations to code containing calls to functions that are subtype of `Core.Closure`.
In cases like the following code, where a variable defined in the parent scope of a closure is used inside the closure and could potentially be reassigned in the parent scope, it seems to get boxed even if it is never reassigned within the closure itself.
This boxing appears completely unnecessary to me. Would it be possible to make a simple change to lowering to fix this issue?
The text was updated successfully, but these errors were encountered: