Creating a view (SubArray) of a Vector allocates memory

[tkoolen]

On 0.5 as well as the latest nightly, for matrices,

@benchmark view(a, 1:2, 1:2) setup = (a = rand(3, 3))

results in zero allocation.

However,

@benchmark view(a, 1:2) setup = (a = rand(3))

results in 48 bytes of allocation and is almost 6 times slower. I haven't been able to figure out what in subarray.jl causes this.

[prcastro]

I tracked a difference in memory allocation to index_ndims, but I still can't tell why this is happening.

[yuyichao]

I highly doubt you are testing the right thing. This sounds like a defect of BenchmarkTools since I believe both should actually allocate. view(a, 1:2) does seem to be slower and results in more allocation than view(a, 1:2, 1:2) and I assume that's what #19259 fixes.

[tkoolen]

Wow, thanks for the quick response!

@yuyichao, the only open issue I see in BenchmarkTools that could be related is JuliaCI/BenchmarkTools.jl#26, but that seemed to not be an actual defect. I use BenchmarkTools a lot, so if there are cases where I can't rely on it, I'd be very interested in learning more about those.

To me, it conceptually doesn't make sense that view(a, 1:2, 1:2) should allocate, since a is already allocated, 1:2 is isbits, the SubArray resulting from view has no abstract members, and it contains just a reference to a plus some isbits offset/stride/index information.

[tkoolen]

Well, I guess I'm wrong :-)

[jrevels]

The missing allocation info here is definitely a BenchmarkTools issue, see my comment here.

[andyferris]

To me, it conceptually doesn't make sense that view(a, 1:2, 1:2) should allocate, since a is already allocated, 1:2 is isbits, the SubArray resulting from view has no abstract members, and it contains just a reference to a plus some isbits offset/stride/index information.

Currently, if it is not isbits, it isn't stack allocated. Because the view "struct" contains a reference to mutable a, my understanding is that the object will have to be allocated on the heap and GC'ed afterwards. It will only allocate a small amount of memory - enough for the 1:2 and a pointer to a (and anything else a view keeps around) and is "cheap" in the sense that it doesn't copy data in a.

Putting it on the stack requires scanning the stack for pointers that GC needs to know about, and this is tricky to do precisely (apparently - I'm no expert).

[andyferris]

BTW, I do agree with @yuyichao and I'm still worried that BenchmarkTools.jl misses at least some allocations. I'd love to be proven wrong, but...

[tkoolen]

Currently, if it is not isbits, it isn't stack allocated. Because the view "struct" contains a reference to mutable a [...]

D'oh, I knew that; I was just confused.

[jrevels]

I'm still worried that BenchmarkTools.jl misses at lease some allocations.

See JuliaCI/BenchmarkTools.jl#28