<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye" -->

---
title: What garbage collection actually costs · Shivanshu Agrawal
description: A deep dive into how garbage collection actually costs performance: not bytes of memory, but the number of live objects and references a collector must walk....
canonical: https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: What garbage collection actually costs · Shivanshu Agrawal | daily.dev
og:description: A deep dive into how garbage collection actually costs performance: not bytes of memory, but the number of live objects and references a collector must walk....
og:url: https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye
og:image: https://api.daily.dev/og/posts/vPTkCflye.png
og:image:alt: What garbage collection actually costs · Shivanshu Agrawal
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# What garbage collection actually costs · Shivanshu Agrawal

**[Hacker News](https://daily.dev/sources/hn)** · 12 min read · 7 upvotes · 0 comments

## Summary

A deep dive into how garbage collection actually costs performance: not bytes of memory, but the number of live objects and references a collector must walk. Explains the difference between GC-based memory management (Go, Java), manual/compiler-verified management (C, Rust), and reference counting (Swift, Python). Covers why a GC cycle's cost is proportional to live pointers rather than dead memory, how stack vs heap allocation factors in, and a practical three-phase measurement approach (CPU share, allocation profiling, live-object profiling) for diagnosing GC pressure in Go and Java before attempting optimization. Ends with a checklist for deciding whether GC overhead is worth addressing at all.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://shivanshuag.com/blog/what-garbage-collection-actually-costs>

## Questions this post answers

### why does garbage collection cost more for many small objects than for one large buffer of the same size

A GC cycle charges for objects and references, not bytes of memory. Collecting a 4 GB graph of a million small objects pointing at each other is orders of magnitude more expensive than collecting a single 4 GB buffer, because the collector has to walk every live reference during marking, and cost is proportional to live pointers, not total memory used.

_Developers chasing GC pressure issues can browse deeper explainers on memory internals through daily.dev._

### what should I measure in Go to figure out if garbage collection is actually hurting my program's performance

Start with the runtime/metrics package to see what share of CPU time goes to collection versus your program; if it's small, GC isn't worth optimizing. If it matters, use a heap profile (alloc_objects, alloc_space, or allocs/op and B/op in benchmarks) to find which call sites produce the most garbage, and inuse_objects or inuse_space to see what's actually being retained.

_Teams tuning Go allocation behavior can track this kind of profiling guidance on daily.dev._

### how can I estimate pointer density in a Go or Java heap to know if GC cost will be high

Divide live bytes by live objects to get an average object size, which acts as a rough proxy for how many pointers the collector must follow. A small average size across many objects signals dense pointer chains and higher marking cost, while a large average size with few objects is cheap to collect, since the cost is proportional to live references followed during marking, not raw memory.

_Engineers weighing allocation-heavy designs can keep this kind of GC-tuning reasoning handy via daily.dev._

## Similar posts on daily.dev

- [Garbage Collection: Generational? Incremental? Both\! \(Python Language Summit 2026\)](https://daily.dev/posts/garbage-collection-generational-incremental-both-python-language-summit-2026--nybehi8cs) · Python Insider · 4 upvotes · 1 comments
- [The Ultimate 10 Years Java Garbage Collection Guide \(2016–2026\) – Choosing the Right GC for Every Workload](https://daily.dev/posts/the-ultimate-10-years-java-garbage-collection-guide-2016-2026-choosing-the-right-gc-for-every-wo-gcjhfz5py) · Jakarta EE · 3 upvotes · 0 comments

---

Tags: [#performance](https://daily.dev/tags/performance), [#java](https://daily.dev/tags/java), [#golang](https://daily.dev/tags/golang)

[View this post on daily.dev](https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"What garbage collection actually costs · Shivanshu Agrawal","url":"https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye"},"datePublished":"2026-08-13T15:25:05.233Z","dateModified":"2026-09-14T07:54:18.647Z","description":"A deep dive into how garbage collection actually costs performance: not bytes of memory, but the number of live objects and references a collector must walk....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9118c9bbbb0247f25b282393d683a37e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9118c9bbbb0247f25b282393d683a37e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,java,golang","timeRequired":"PT12M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"What garbage collection actually costs · Shivanshu Agrawal"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/what-garbage-collection-actually-costs-shivanshu-agrawal-vptkcflye#faq","mainEntity":[{"@type":"Question","name":"why does garbage collection cost more for many small objects than for one large buffer of the same size","acceptedAnswer":{"@type":"Answer","text":"A GC cycle charges for objects and references, not bytes of memory. Collecting a 4 GB graph of a million small objects pointing at each other is orders of magnitude more expensive than collecting a single 4 GB buffer, because the collector has to walk every live reference during marking, and cost is proportional to live pointers, not total memory used. Developers chasing GC pressure issues can browse deeper explainers on memory internals through daily.dev."}},{"@type":"Question","name":"what should I measure in Go to figure out if garbage collection is actually hurting my program's performance","acceptedAnswer":{"@type":"Answer","text":"Start with the runtime/metrics package to see what share of CPU time goes to collection versus your program; if it's small, GC isn't worth optimizing. If it matters, use a heap profile (alloc_objects, alloc_space, or allocs/op and B/op in benchmarks) to find which call sites produce the most garbage, and inuse_objects or inuse_space to see what's actually being retained. Teams tuning Go allocation behavior can track this kind of profiling guidance on daily.dev."}},{"@type":"Question","name":"how can I estimate pointer density in a Go or Java heap to know if GC cost will be high","acceptedAnswer":{"@type":"Answer","text":"Divide live bytes by live objects to get an average object size, which acts as a rough proxy for how many pointers the collector must follow. A small average size across many objects signals dense pointer chains and higher marking cost, while a large average size with few objects is cheap to collect, since the cost is proportional to live references followed during marking, not raw memory. Engineers weighing allocation-heavy designs can keep this kind of GC-tuning reasoning handy via daily.dev."}}]}
```

