[ANN] ArrayAllocators.jl v0.3 composes with OffsetArrays.jl v1.12.1+ for faster zeros with offset indexing

[Sukera]

@Benny

Your package was a cool read! And as I somewhat picked up from the reading, calloc makes the bits 0 but not the elements zero, so I’ll watch out for that:

Indeed - if “blob of zeros” is not a valid representation for your type, just using calloc will not help you.

@Benny

I do have a question, though, if the array allocation is only deferred until next setindexing, am I right in thinking that alone would not improve performance? That the only scenario where I can save allocation time is if my OS has preallocated pages of 0s?

Sort of. In general it depends on how your OS is handling calls to calloc in the libc you’re using. Linux at least has a dedicated zeroed page, to allow reads from calloced memory to be fast, but this of course doesn’t help with writes - the first write still has to allocate a page, which takes time. So in effect, the time an allocation takes is moved from the calloc call to the first real use of the memory.

There’s a bunch of discussion in this related thread:

Faster zeros with calloc

Abstract TL; DR zeros_via_calloc is a potentially faster version of zeros that is comparable to Array{T}(undef, ...) and numpy.zeros. function zeros_via_calloc(::Type{T}, dims::Integer...) where T ptr = Ptr{T}(Libc.calloc(prod(dims), sizeof(T))) return unsafe_wrap(Array{T}, ptr, dims; own=true) end # Windows benchmark julia> @btime zeros_via_calloc(Float64, 1024, 1024); 12.400 μs (2 allocations: 8.00 MiB) julia> @btime zeros(Float64, 1024, 1024); 1.652 ms (2 allocations: 8.00 MiB)…

but I personally don’t think calloc is a good idea, since it can mask performance problems due to the time being spent no longer being directly linked to the original allocation.