GC Pressure
In languages with garbage collection (like Java, C#, or Go), the runtime periodically reclaims memory that your code no longer uses. That process is convenient, but it isn’t free.
GC pressure builds up when your program allocates lots of objects quickly—often because it’s turning every message into new temporary structures, strings, or copies. The faster you allocate, the more the garbage collector has to work to keep memory under control.
In market data pipelines, high GC pressure often shows up as latency spikes. The system may be fast most of the time, but occasional pauses or slowdowns happen when the runtime needs to reclaim memory and compact or scan heaps.
Why It Matters
Real-time market data workloads care about consistent processing time. High GC pressure can increase tail latency, making quotes or trades appear “bursty” even when the network feed is steady.
What causes high GC pressure in streaming market data systems?
Common causes include per-message allocations (creating new objects for every update), excessive string parsing, building temporary collections, and copying payloads between stages. High message rates amplify these patterns quickly. The result is more frequent GC cycles and larger heaps to scan.
How can you reduce GC pressure without changing the language?
You can often reduce allocations by reusing buffers, using object pools carefully, avoiding unnecessary conversions, and choosing data structures that don’t create lots of temporary objects. Another practical step is to separate the hot path (ingestion + parsing) from heavier downstream work so that bursts don’t multiply allocations. Profiling allocation hotspots is usually more effective than guessing.
How does GC pressure relate to latency spikes?
Garbage collection work competes with your application’s normal work for CPU time. Even “concurrent” collectors may introduce brief pauses or reduce throughput while they scan memory. That shows up as higher p99/p999 processing times, which can be more damaging than a small drop in average speed.
Real-World Example
A service parses every incoming trade into a new object graph and converts timestamps into multiple string formats. At peak rates, GC runs frequently and p99 processing latency jumps. After switching to reusable message buffers and keeping timestamps in numeric form until needed, GC frequency drops and tail latency tightens.
GC pressure and Market Data API
If you consume CoinAPI’s Market Data API at high update rates, GC pressure can become the hidden reason your client falls behind during volatility. Reducing allocations in your parsing and normalization code can help you keep up with bursts of quotes and trades more reliably.