This is usually good advice, but it doesn’t always mean you should completely avoid touching the heap. Sometimes it just means you should avoid repeated allocations and instead allocate reusable containers once before entering the hot loop. A corollary is that in any piece of code for which you care about microbenchmarks (i.e., you’re using BenchmarkTools.jl rather than just @time) you should consider taking preallocated memory as an argument, rather than performing heap allocations within that code itself.
I happen to have programmed in the time when the maximum available RAM was < 640 kB, so I know the value of reusing memory 
1 Like
Great! But I think this is a bit different. We’ve usually got plenty of RAM, so it’s not about avoiding OOM, it’s about not wasting CPU cycles on the allocator/GC in performance sensitive parts of the code. Just sharing my interpretation of the frequent “avoid allocations” admonitions, which I don’t think should be understood as “avoid the heap”.
1 Like
I think it’s the context and how stack/heap allocations are used in practice. Personal computers in the last couple decades can allocate quite a lot of memory, whereever it is, and Julia is one of the languages that needs a lot to just work (well, we’ll see where juliac goes). People in this world tend to worry about heap allocation or GC latency, which stack allocation doesn’t need to deal with. It’s also generally harder to allocate bigger things on the stack because nobody really wants to do that; the heap allows dynamic sizing and easier sharing across methods. Smaller stack allocations in this context are practically almost free; you’d usually need runaway recursion to hit the limit. Even hefty SVectors often don’t crash our systems, it just results in worse performance (compilation, copying).
If more people reach these or smaller systems with juliac, I expect stack allocations aren’t going to be perceived as free as they are today, and maybe we’d get some way to profile them on a bigger system.