rf
rf
May 18, 2017 · 1 min read

Did the big allocations of RAM contain pointers, directly or indirectly (actual pointers, strings, interface or function values, maps, or slices)?

If you allocate a giant []byte, []int, etc., or an array of pointerless structs, Go treats it as ‘noscan’ so the GC’s scanning phase gets a break. That can require gimmicks like using numeric IDs/offsets instead of pointers, much as if you were implementing an on-disk database, but you can continue to use language constructs to allocate instead of having to go to the OS. (And noscan allocs can still add time to the sweep phase, but I think that’d be low for a few large allocations.)

Also sort of curious what the user-facing app latency numbers looked like in the version where the GC was spending a lot of time. That’s one thing that you can sort of only understand from real apps and I haven’t seen much out there about.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store