Crossposting this from zulip to reach more people and because it’s a getting a bit long. tl;dr After upgrading to 1.6 my code runs 50 times slower, it seems to be caused by broadcasting with calls to materialize increasing to about 140x their number in 1.5.4. Nikolai: I just restarted my developm…

Seeing that stacktrace I have a hunch that this might be the same type of regression as in Performance regression when recursively traversing nested types. · Issue #40302 · JuliaLang/julia · GitHub . In that case inference: SCC handling missing for return_type_tfunc (#39375) · JuliaLang/julia@fd8f97e…

You’re benchmarking it wrong. Julia v1.5.4: julia> using BenchmarkTools julia> t = rand(10); julia> @benchmark $t .- $t BenchmarkTools.Trial: memory estimate: 160 bytes allocs estimate: 1 -------------- minimum time: 34.528 ns (0.00% GC) median time: 35.873 ns (0.00% GC) …

Thanks, I didn’t know that. In your benchmark 1.6 is still notably slower though. But it’s probably not just due to broadcasting then, but that isn’t really the main problem.

[image] imLew: In your benchmark 1.6 is still notably slower though. Is a less-than-2-percent slowdown “notably slower”? That’s very well within noise, if I repeat the benchmarks I get # julia v1.5.4 julia> @benchmark $t .- $t BenchmarkTools.Trial: memory estimate: 160 bytes allocs es…

Not sure where you get <2%. Both mean and median times are ~10% longer in your 1.6 benchmark. Anyway, not the point.

[image] imLew: Not sure where you get <2% The minimum time, which is what BenchmarkTools cares about, as detailed in their paper .

Here are screenshots of the output from StatProfilerHTML [2021-04-22-121911_2070x1428_scrot] [2021-04-22-121855_2046x1444_scrot]

A hell of a hunch!, this was it. At tag 1.6.0 I reverted the commit you linked and the performance returned to what it had been at 1.5.4.

[image] imLew: A hell of a hunch!, this was it. :cool:

I was able to get my code running at normal speeds in 1.6 by removing a function call that returned an anonymous function. As far as I understood those links the problem was unknown return types of functions. But since the offending commit was actually a fix for something else, does that mean this…

[image] imLew: But since the offending commit was actually a fix for something else, does that mean this a kind of lucky bug where breaking one thing allowed another to run fast? Could be, I am not very familiar with the code that commit touches. [image] imLew: Should I create an MWE? …

Huge Performance drop after upgrading to 1.6

General Usage Performance

imLew April 22, 2021, 10:19am 7

Here are screenshots of the output from StatProfilerHTML

Topic		Replies	Views
Is there way to avoid `materialize` and `copy`? Performance	20	3400	November 15, 2018
Large performance regression of vectorized functions on master General Usage	4	675	July 25, 2018
Drop of performances with Julia 1.6.0 for InterpolationKernels Performance	40	2775	April 1, 2021
Inconsistent performance Julia 1.6 vs 1.5 on Linux New to Julia	10	700	August 9, 2021
Confusion on performance when using the broadcasting macro @. vs explicit . operators Performance	7	238	March 27, 2025

Huge Performance drop after upgrading to 1.6

Related topics