Measure Green Tea at the service boundary
Go's Green Tea collector can reduce GC CPU work. Evaluate allocation patterns, memory limits and service outcomes before turning that into a savings claim.
By 
Paul. Languages and frameworks
A faster garbage collector earns a place in a service through evidence about that service. Green Tea offers a useful example: reduced collection work can release CPU capacity, but the reader waiting for a response experiences the whole request. Measure that boundary before promising lower latency or a smaller hosting bill. The collector's result and the business outcome need different evidence.
Looking back from November 2026, the chronology matters. Go 1.25 was released on 12 August 2025, with an experimental collector available through explicit opt-in. The 29 October Green Tea explanation described that existing experiment. October was the detailed explanation, rather than the release of Go 1.25. A maintenance decision should preserve those dates even when its practical lesson remains useful.
Locality explains the opportunity
The October explanation describes page-oriented marking work, with separate seen and scanned metadata. Accumulating work on pages improves locality; a page can return to the queue. Its reported 10–40% GC CPU reduction belongs to the authors' benchmark suite, with regressions possible. In Go 1.25, the build-time opt-in was GOEXPERIMENT=greenteagc. Those are the source's observations and historical configuration, not measurements of your application.
That mechanism suggests what to investigate. A workload allocating many related objects may present a different scanning problem from one whose useful references are dispersed. Request rate alone will not describe the difference. An evaluation should retain enough information about object lifetimes and allocation behavior to explain why a collector result changes between workloads.
Memory constraints also belong in the comparison. A service running with a different memory limit or collection configuration is answering a different capacity question. Changing the collector while also changing memory allowance can produce a useful deployment, but it makes attribution harder. Record the two decisions separately so a later operator can explain what bought the improvement.
Keep historical flags separate from version guidance
The Go 1.26 release notes, read in November 2026, say Green Tea became the default in that version. That maintained version document answers a different question from the October 2025 post. It establishes the 1.26 default; it does not establish the exact settings or support position of every subsequently deployed Go binary.
Begin a present-day assessment with the compiler and build configuration actually used by the product. Preserve that identity with the executable being evaluated. Otherwise an experiment flag copied from an older article can become a misleading description of what is already enabled. An upgrade may also include unrelated compiler and library changes, which deserve their own release consideration.
A fair comparison holds the application revision and external conditions steady as far as practical. Where they cannot remain steady, record the difference. There is little value in attributing a response-time improvement to collection if the second run also uses a warmer database cache or a different upstream service. This is a proposed evaluation method; no benchmark was performed for this article.
A CPU denominator is not a latency result
Start with the fraction of total CPU consumed by collection. A reduction within that fraction cannot be copied unchanged onto total service CPU. Even an accurately calculated overall CPU saving would still leave the latency question open. Requests may wait on storage, external APIs or a queue whose behavior changes sharply near saturation.
Separate the acceptance conditions. Collection CPU can test the proposed runtime mechanism. Total CPU at comparable useful throughput can test capacity. Response-time distributions and error rates can test the user-facing consequence. Record memory use as well, because a service that finishes faster while exceeding its operational memory allowance has failed a different constraint.
Choose traffic that represents important work, including the allocation-heavy operation that motivated the change. A short health-check loop may be easy to repeat while saying little about report generation or large response assembly. Define which operations the comparison covers and which remain unexamined. That limit is more useful than calling an arbitrary workload representative without explanation.
Keep completion rates alongside throughput. A client that abandons slow requests can make successful responses look faster while the product becomes less reliable. Similarly, an increasing backlog can hide a capacity shortfall during a short observation window. The proposed assessment should answer whether the same useful work finished under comparable conditions, rather than whether one isolated metric moved.
Hosting savings require a second decision
The strongest counterargument is that runtime improvements can be worthwhile without an elaborate experiment. A supported toolchain update may already be required for maintenance, and a collector that uses less CPU may add welcome headroom. A low-risk application with ample capacity need not build a performance research project merely to adopt an ordinary update.
The distinction matters when the update is sold as a financial or latency result. Hosting bills depend on purchased capacity and billing rules. Extra headroom may improve resilience without allowing any machine to be removed. A cost claim needs evidence that the deployment can change while retaining its availability and recovery requirements. Runtime benchmark percentages cannot supply that evidence.
The conclusion also has a narrow applicability limit. If collection contributes little to the service's bottleneck, deeper investigation elsewhere may be more useful. If the allocation pattern performs poorly under the collector, the general benchmark range cannot overrule the local result. Preserve a recoverable build and decide in advance which observed failure would stop rollout.
For software maintenance, request a record of the runtime version, workload covered and release conditions. The deliverable should explain whether the update improves measured service behavior, simply keeps the application maintained, or still needs investigation. Any later claim about latency or expenditure must be supported at that level.