
dylanmc
Rust Brain Teasers: "Stacking Boxes" heap vs. stack performance explanation
Title: Rust Brain Teasers, page 47
“Because of the extra steps required for heap read/write access—particularly with frequent allocations—accessing data on the heap can be a lot slower than accessing data on the stack. Why? Because the CPU’s memory cache will try its best to keep your heap data available.”
This explanation doesn’t really make sense - both heap and stack are cached, and in both cases “the memory cache will try its best”. I think this might be trying to say something about stack memory has better locality, so the cache has an easier job, but even so, the above paragraph struck me as misleading and/or confusing.
Marked As Solved

herbert
Thank you! I’m inclined to agree, I’ll see if I can make that explanation a bit clearer for the next beta.
There’s really two things at play with stack vs. heap cache. One is locality: your stack is almost always in one of the cache levels because your program uses it constantly. The stack being tiny also helps with this: it’s easy to fit into the cache, so there’s an even higher probability that it will be there (and if it isn’t, it’s a fast operation to load a tiny stack frame into cache vs. an arbitrarily sized heap object).
Good catch - thank you.
Popular Prag Prog topics









Modern Front-End Development for Rails - application does not start after run bin/setup (page xviii)

Other popular topics










Latest in PragProg
Latest (all)
Categories:
Popular Portals
- /elixir
- /opensuse
- /rust
- /kotlin
- /ruby
- /erlang
- /python
- /clojure
- /react
- /quarkus
- /go
- /vapor
- /react-native
- /v
- /wasm
- /django
- /security
- /nodejs
- /centos
- /rails
- /haskell
- /fable
- /gleam
- /swift
- /js
- /deno
- /tailwind
- /assemblyscript
- /laravel
- /symfony
- /phoenix
- /crystal
- /typescript
- /debian
- /adonisjs
- /julia
- /arch-linux
- /svelte
- /spring
- /c-plus-plus
- /flutter
- /preact
- /actix
- /java
- /angular
- /ocaml
- /zig
- /kubuntu
- /scala
- /zotonic
- /vim
- /rocky
- /lisp
- /keyboards
- /html
- /emacs
- /vuejs
- /nim
- /elm
- /nerves