← Back to article listing


December 8, 2021
Share this

Garbage Collection(GC) induced latency in trading applications can be a major problem. OnixS shows how to measure the GC load of the OnixS FIX Engine .NET Core SDK using the built-in .NET API demonstrating zero GC load.

Measuring and avoiding GC in the critical path

When GC blocks working threads, the latency increases dramatically and you don’t know when it’s going to hit. For performance-critical applications it is preferable to avoid garbage collection by using software designed not to allocate memory in the critical path.

And very importantly to verify that it doesn’t.

This article shows how OnixS measures GC using the built-in .NET API, and describes its usage to test the GC load of the OnixS ultra-low latency .NET Core FIX Engine to send and receive one million FIX messages without producing any GC load.
You can read the full technical reference here.

Or, learn more about the OnixS .NET Core FIX Engine / .NET 5 FIX Engine here.

Request An Evaluation Download or Demo

Request a free 30-day evaluation download or a hands-on demonstration walk through.

 

Is your FIX Engine specifically designed for ultra-low latency, high-frequency trading infrastructure?