Repository navigation
JLArrays 0.4 takes ~4.5 s to load (was 0.5 s), spent activating its methods #807
Description
Claude:
using JLArrays got about 9x slower with JLArrays v0.4.0 / GPUArrays v12.0.0.
Julia 1.13.1, macOS aarch64, fresh process, after precompiling:
| JLArrays 0.3.3 + GPUArrays 11.5.16 | JLArrays 0.4.0 + GPUArrays 12.0.0 | |
|---|---|---|
using JLArrays |
0.47 to 0.54 s | 4.52 to 4.64 s |
| allocated | 52 MiB | 1850 MiB |
| JLArrays precompile | 0.8 s | 4.8 s |
| invalidated method instances | 198 | 1842 |
- Where: loading SIMD, AcceleratedKernels and GPUArrays first takes 0.07, 0.23 and 0.34 s. The rest is JLArrays' own image:
@time_importsgives it 4.4 s with no compilation time. - Profile: almost all of that is
jl_activate_methods→jl_method_table_activate→type_morespecific_(subtyping), i.e. inserting JLArrays' methods into the method tables. The new methods insorting.jl,accumulate.jlandfindall.jl(onAnyJLArray) are the likely cause. - Invalidations: most of the new ones come from SIMD.jl, newly pulled in via AcceleratedKernels (
!=,>=,>insimdvec.jl, about 1400 instances).
Repro:
using Pkg; Pkg.activate(temp=true); Pkg.add(name="JLArrays", version="0.4")
# then in a new process with that environment
@time using JLArraysIt shows up in Julia's TTFX CI: JLArrays/Matrix-Multiplication-On-Gpu-Like-Arrays load went from 0.9 s to 8.4 s on macOS when the job picked up these releases (perf.julialang.org).
Written with Claude Code (Claude Opus 5.5).
Activity
IanButterworth commentedon Oct 7, 2026
Claude:
Same on Julia master, and JuliaLang/julia#62658 (fewer recorded backedges) cuts the invalidations but not the load time:
using JLArrays(3 runs each)So the cost is in adding JLArrays' methods to the method tables, not in invalidating code.
Written with Claude Code (Claude Opus 5.5).
IanButterworth commentedon Oct 24, 2026
I would say this is fixed on master.... 😂 JuliaLang/julia#64014 (comment)