Go 1.25 Greentea GC vs Classic: HydrAIDE 1M Swamp Test Shows +22% CPU Efficiency, -8% Memory

Go 1.25 new Greentea GC vs. classic GC. 1 Million Swamp stress test with HydrAIDE: +22% CPU efficiency, -8% memory, but rarer long spikes

Introduction – Why now, why HydrAIDE?

With the release of Go 1.25, an exciting experimental feature has arrived: the Greentea GC, a new garbage collector mode that promises to reduce GC overhead by 10–40%. But what does this mean in practice? Does it bring noticeable speed-ups, or is it just theoretical fine-tuning?

This is where HydrAIDE comes into play: an open-source (Apache 2.0) data engine that simultaneously provides strongly typed storage, pub/sub, caching, and real-time data services — all without additional infrastructure. Data is always hydrated into memory, and references are automatically dropped when no longer needed, allowing the GC to immediately reclaim memory.

This model makes HydrAIDE uniquely suited to test the behavior of Go’s new GC under real, production-like loads. No need for synthetic microbenchmarks — we can just create 1 million Swamps and wait for the GC to do its job.

👉 Direct test code: hydra_gc_test.go

👉 Full project: github.com/hydraide/hydraide

Good to know – How HydrAIDE manages Swamps

HydrAIDE stores all data in Swamps (mini-databases). These appear as physical folders in the filesystem, with each Swamp fully isolated. When a Swamp is accessed for the first time, the system automatically hydrates it into memory — loading the data into RAM. If the Swamp remains idle for longer, HydrAIDE closes it and removes it from memory while keeping the content safely persisted on disk. This means memory always only contains what is needed, and only for as long as it is needed.

This logic ensures efficient memory usage, automatically keeping the GC environment clean.

Why is this test special?

• 
  Real allocation pressure: creating 1 million Swamps, each with its own Treasure. For those familiar with traditional databases, imagine opening 1 million separate mini-databases (tables or collections), each with at least one record. This generates an enormous number of objects on the heap and creates a true stress scenario for the GC.


• 
  Deterministic idle-close: after 30s of inactivity, HydrAIDE automatically clears references → all objects instantly become GC-eligible. Think of it like dropping all pointers to a table’s rows at once: the data remains on disk, but memory is free. This gives the GC a crystal-clear signal about what can be reclaimed.


• 
  GC-close metrics: we used the runtime/metrics API directly → precise CPU, heap, and pause times. Introduced in Go 1.20, this API provides stable, low-level runtime measurements without external profilers. It allows us to track GC cycles, CPU usage, heap size, and pause distributions.


• 
  Straightforward comparison: the same binary runs once with the legacy GC, once with Greentea GC.

Background – What does Greentea GC promise?

Greentea GC is an experimental collector introduced in Go 1.25 that improves marking/scanning of small objects with better locality and CPU scalability. The Go team expects 10–40% GC overhead reduction in real workloads. Enabling it: build with GOEXPERIMENT=greenteagc. Go 1.25 also introduced container-aware dynamic GOMAXPROCS and the runtime/trace Flight Recorder, improving reproducibility and diagnostics.

How we measured the test

We defined two distinct phases to measure GC behavior. For this we used the runtime/metrics API, which reports GC cycles, CPU usage, heap sizes, and pause time histograms.

• Phase A – Create burst: we created 1,000,000 Swamps, each with at least one Treasure. For the test, we specifically used HydrAIDE’s in-memory Swamp mode instead of filesystem-based Swamps, ensuring no disk I/O influenced the results. Each creation included a small write and save in memory, simulating a real, high-allocation workload. This produced a massive number of heap objects, ideal for stress-testing the GC.




• Phase B – Idle-close window: HydrAIDE’s built-in idle-close logic was used: after 30 seconds of inactivity, all Swamps automatically closed, dropping references in memory. We then waited another 5 seconds to ensure everything was GC-eligible. In this phase, we measured the GC’s behavior during reclamation and memory release.

Important: this phase also ran entirely in-memory, with no disk writes. HydrAIDE’s idle-close mechanism guarantees references vanish deterministically, giving the GC clear visibility. This ensures reproducibility and measurement accuracy.

What results did we get?

The following shows how the classic GC and the new Greentea GC performed across the two phases.

Summary table

Interpretation in words

• 
  Speed: Greentea GC delivered ~5% faster runtime under the create burst.


• 
  CPU efficiency: it used 22% less CPU time for GC — the biggest win.


• 
  Memory usage: it finished with 8% smaller heap → better memory reclamation.


• 
  Pause times: pause times represent short stop-the-world events where all goroutines are paused for GC. On average (p50, p95) they are the same, but p99 shows Greentea occasionally introduces longer pauses.


• 
  Idle phase: neither GC triggered extra cycles → stable operation.

Conclusion

👉 Greentea GC is clearly advantageous when CPU and memory efficiency are critical. However, in latency-sensitive applications (e.g., real-time APIs), one must consider the occasional longer p99 pauses.

For HydrAIDE, this has particular significance: handling massive numbers of Swamps and Treasures in memory means every GC improvement directly translates into speedups and lower resource usage. Running this test was a pleasure. It demonstrated how effective the Go GC already was, and how much this new Greentea enhancement benefits systems like HydrAIDE.

Special thanks go to the Go developers for this excellent improvement.

Links and contacts

👉 Direct test code: hydra_gc_test.go

👉 Full project: github.com/hydraide/hydraide

👉 Community & support: HydrAIDE Discord

👉 Contact: [email protected]