using Makie allocations regression between 1.10.2 and 1.10.3

[jaakkor2]

@time using Makie # v0.21.2

Allocations increase quite a bit between Julia v1.10.2 and v1.10.3

# 1.10.2 from juliaup
2.318577 seconds (2.48 M allocations: 165.164 MiB, 2.60% gc time, 1.76% compilation time: 40% of which was recompilation)
# 1.10.3 from juliaup
2.789395 seconds (3.81 M allocations: 399.864 MiB, 10.31% gc time, 1.51% compilation time: 42% of which was recompilation)
# 1.10.4 compiled in cygwin
2.683201 seconds (3.63 M allocations: 394.846 MiB, 11.36% gc time, 1.57% compilation time: 41% of which was recompilation)
# 1.11.0-beta2 from juliaup
3.687167 seconds (5.19 M allocations: 419.380 MiB, 8.97% gc time, 7.49% compilation time: 75% of which was recompilation)

I bisected this to

Last good e44f1ab0082a7a4276e9384092b0f513cc991837

• Add missing GC_POP() in emit_cfunction (#53809) 2.277758 seconds (2.41 M allocations: 162.490 MiB, 4.79% gc time, 1.81% compilation time: 42% of which was recompilation)

First bad 396f5d128cc48e6b3dc7526fb304cc349c1e8e1f

• typeintersect: fix UnionAll unaliasing bug caused by innervars. (#53553) 2.746628 seconds (3.61 M allocations: 393.176 MiB, 11.02% gc time, 1.51% compilation time: 41% of which was recompilation)

Above happens on Windows and Linux, here is versioninfo() for Windows

Julia Version 1.10.3
Commit 0b4590a550 (2024-04-30 10:59 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 20 × 13th Gen Intel(R) Core(TM) i7-1370P
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
Threads: 20 default, 0 interactive, 10 GC (on 20 virtual cores)
Environment:
  JULIA_PKG_PRECOMPILE_AUTO = 0

[oscardssmith]

given that the regression was a bugfix, it seems unlikely to be fixable

[KristofferC]

I wouldn't say that. Bugfixes introduce perf regressions all the time but they can often be tweaked to keep the bug fixed while fixing the perf regression.

[KristofferC]

cc @N5N3

[N5N3]

It seems impossible that the doubled allocation all comes from UnionAll unaliasing. So there might be some unexpected side effect. I will take a look when I have time, but not sure if there's a (quick) fix.

[N5N3]

Tried to test this a bit locally, It turns out that 02f27c24929ab2561bcb21d3f58c1d313ae5d6e8 caused this "regression". I have verified that type intersection does generate some result with free TypeVar on v1.10.2 during Makie's pre-compilation. IIUC, this would change the result of inference and "simplified" the compiled signature, thus make loading faster. From this perspective, this is not a regression of type intersection itself.

BTW, I also noticed that the inputs of jl_type_intersection_env_s might contain free TypeVar even during bootstrap. And obviously, these free TypeVars do not come from type intersection. @vtjnash Is this expected?