Reputation: 927
I am running the following routine in with --track-allocation=user
. The routine is called in a for loop. Still I am surprised at the allocation generated in the first line: I would expect numqps
to be allocated on the stack and thus not contributing to the final allocation count.
- function buildpoints{T}(cell::Cell{T}, uv)
-
2488320 numqps::Int = size(uv,2)
12607488 mps = Array(Point{T}, numqps)
0 for i in 1 : numqps
0 mps[i] = buildpoint(cell, Vector2(uv[1,i], uv[2,i]))
- end
-
0 return mps
-
- end
EDIT: A bit further along in the memory profiling output I find:
1262976 numcells(m::Mesh) = size(m.faces,2)
It seems the size
function on Arrays is implemented not very efficiently?
Upvotes: 0
Views: 246
Reputation: 927
Apparently I was calling size
on a variable declared as
type MyType{T}
A::Array{T}
end
So the type of A
was only partially declared, i.e. only the eltype was supplied, not the number of dimensions. I noticed similar allocation overheads when accessing elements (A[i,j]
). Allocation disappeared when I declared instead
type MyType{T}
A::Array{T,2}
end
Upvotes: 1
Reputation: 5746
In interpreting the results, there are a few important details. Under the user setting, the first line of any function directly called from the REPL will exhibit allocation due to events that happen in the REPL code itself. More significantly, JIT-compilation also adds to allocation counts, because much of Julia’s compiler is written in Julia (and compilation usually requires memory allocation). The recommended procedure is to force compilation by executing all the commands you want to analyze, then call Profile.clear_malloc_data() (page 594) to reset all allocation counters. Finally, execute the desired commands and quit Julia to trigger the generation of the .mem files.
Upvotes: 0