Open nalimilan opened 12 months ago
The new commit implements a simpler approach which is fast for concrete eltypes but super slow for complex type unions as the compiler doesn't infer an element type more precise than Any
julia> @btime mean(x);
68.529 ms (4 allocations: 64 bytes)
julia> @btime mean(y);
550.489 ms (0 allocations: 0 bytes)
julia> @btime mean(z);
2.752 s (25300984 allocations: 386.06 MiB)
It looks like you're reimplementing undocumented Base
internals, doesn't that have potential to break in future Julia versions?
Yes, but given that Statistics is an stdlib any breakage would be noticed in Julia even before merging it. I'm more concerned about performance issues introduced by the PR...
Override the standard
mapreduce
machinery to promote accumulator type. This avoid calling the function twice, which can be confusing.Fixes #49 but with a more general solution than https://github.com/JuliaStats/Statistics.jl/pull/80/.
Cc: @stevengj @kagalenko-m-b
Unfortunately, performance drops for a
Float64
vector:This is simply due to
sum
being slower wheninit
is provided as it callsmapfoldl
under the hood in that case: