I am trying to resolve a type stability problem in a function where some local variables are showing up as the type Core.Box when I run @code_warntype. I’ve narrowed the cause to where I use a comprehension or generator with those variables as inputs, and those variables can be modified later in the function. ’ Here’s a MRE. In the second function NoBox() with the line x = 1.0 commented out, x is correctly reported as Float64. function box() x::Float64 = rand() y = 0.0 if x > 0 y = mean((round(x) for _ in 1:100)) end x = 1.0 return(x, y) end function nobox() x::Float64 = rand() y = 0.0 if x > 0 y = mean((round(x) for _ in 1:100)) end #x = 1.0 return(x, y) end As a workaround, if I move the equivalent in my code of the line y = mean((round(x) for _ in 1:100)) to its own function, it also works as expected and runs several times faster. I usually try to break up my code in a way that is pretty natural to function barriers, but this originally seemed like too trivial a step to separate out. I’d appreciate any insight into why this is happening and if there’s a proper way to do this.

This is so confusing for me too: julia> function box() x::Float64 = rand() y = 0.0 if x > 0 y2 = mean((round(x) for _ in 1:100)) end x = 1.0 return(x, 1) end box (generic function with 1 method) julia> function no_box() x::Float64 = rand() y = 0.0 #if x > 0 # y2 = mean((round(x) for _ in 1:100)) #end x = 1.0 return(x, 1) end no_box (generic function with 1 method)

I believe this is the famous variable captured in closure bug.

Performance Tips · The Julia Language has some more information about this particular problem.

Yeah but in this case the type annotation does not help. I’m aware of the captured variable bug but it’s kinda annoying that it’s so re-occurring. Here it seems that the comprehension captures x? What helps is. function box_fixed() x::Float64 = rand() y = 0.0 let x=x if x > 0 y2 = mean((round(x) for _ in 1:100)) end end x = 1.0 return(x, 1) end I often encountered cases where this has huge performance penalties and as a user this is really worrisome.

Correct, Meta.@lower is your friend here: julia> Meta.@lower mean(x for _ in 1:100) :($(Expr(:thunk, CodeInfo( @ none within `top-level scope` 1 ─ $(Expr(:thunk, CodeInfo( @ none within `top-level scope` 1 ─ global var"#5#6" │ const var"#5#6" │ %3 = Core._structtype(Main, Symbol("#5#6"), Core.svec(), Core.svec(), Core.svec(), false, 0) │ Core._setsuper!(%3, Core.Function) │ var"#5#6" = %3 │ Core._typebody!(%3, Core.svec()) └── return nothing ))) │ %2 = Core.svec(var"#5#6", Core.Any) │ %3 = Core.svec() │ %4 = Core.svec(%2, %3, $(QuoteNode(:(#= none:0 =#)))) │ $(Expr(:method, false, :(%4), CodeInfo( 1 ─ return x ))) │ #5 = %new(var"#5#6") │ %7 = #5 │ %8 = 1:100 │ %9 = Base.Generator(%7, %8) │ %10 = mean(%9) └── return %10 )))) IMO, this is one of the most surprising and “leakiest” parts of lowering. There is no indication that a closure is created when you write a comprehension, so people don’t know to look for one when trying to hunt down the source of the box. Ideally, there would be a way to stabilize captures in comprehensions which doesn’t require solving the entirety of the closure capture problem.

There is no indication that a closure is created when you write a comprehension, so people don’t know to look for one when trying to hunt down the source of the box. This is certainly part of my confusion. I was trying to comprehend (no pun intended) how the documentation linked by @Zentrik related to this since I did not think I was creating or returning a sub-function but the evaluated result.

Well, that certainly feels awkward and counterintuitive. I’ll stick to separating out the function. It’s a shame because comprehensions, generators, map, etc. are all such workhorses.

I do wonder whether we could fix this by lowering to opaque closures. this is a case where we make the closure and immediately execute it, so making a closure does lose information.

[image] Oscar_Smith: I do wonder whether we could fix this by lowering to opaque closures. this is a case where we make the closure and immediately execute it, … Unless, of course, you keep the generator around: function box() x::Float64 = rand() if x > 0 y = (round(x) for _ in 1:10) end x = 1.0 return y end collect(box()) return a vector of 1.0s.

[image] ToucheSir: There is no indication that a closure is created when you write a comprehension, so people don’t know to look for one when trying to hunt down the source of the box. [image] roflmaostc: Here it seems that the comprehension captures x? The scoping rules say that comprehensions make new local scopes, which use outer local variables; they are built on methods so that requires capturing. Expr(:method... showed up in the lowered code to make the closure. Closure behavior and the performance pitfalls are plainly documented in the sections on comprehensions and generator expressions in Single- and multi-dimensional Arrays · The Julia Language. [image] roflmaostc: let x=x if x > 0 y2 = mean((round(x) for _ in 1:100)) end end If the value of x at a particular point is preferable to capturing the variable x in general, then this is semantically the proper way. [image] Oscar_Smith: variable captured in closure bug. I think this is a fair description because there are feasible ways to mitigate this, but “bug” doesn’t get across the difficulty of mixing apparently straightforward type inference with performant closure implementation. For example, sgaure just pointed out that immediate execution for a particular value cannot be an automatic optimization if the generator persists. Unfortunately, even y = mean((round(x) for _ in 1:100)) does not guarantee that the generator is never reused because mean could cache the generator somewhere for all we know. I assume some compiler effect analysis can address that, but I’m not sure how reliable that is, and it’s moot because boxing is still determined at lowering, far before a call signature is available to trigger compilation. We’d prefer something that works unconditionally and safely.

Help understand boxing

General Usage Performance

Topic		Replies	Views
RFC: Some Ideas to Tackle #15276 - performance of captured variables in closures Internals & Design inference , type-stability , corebox	65	5795	February 16, 2024
Language restriction to solve 15276? Internals & Design	48	4794	May 11, 2018
Weird type instability General Usage question , performance	8	1256	January 5, 2018
Call FastClosures.jl `@closure` in Array Comprehensions? Internals & Design performance , closure , corebox , comprehension	2	1140	February 3, 2023
Surprising slowdown from using array comprehension Performance	8	474	June 4, 2025

Help understand boxing

Related topics