QuickOPC is written in .NET, and the COM interfaces you are using from Delphi are layered on top of it. We have little to no control over how the managed (.NET) is run, and that includes the garbage collector executions.

In theory, it might be possible to improve the behavior using the GC latency mode setting:
- docs.microsoft.com/en-us/dotnet/api/system.runtime.gcsetting...encymode?view=netframework-4.7
- docs.microsoft.com/en-us/dotnet/api/system.runtime.gclatencymode?view=netframework-4.7

There are, however, two issues with it:
1) Currently it is not accessible to you, because it is in a global .NET object which neither Microsoft nor us are exposing to COM .
2) The proper setting would probably be LowLatency or SustainedLowLatency, BUT none of these is meant to be set permanently - they should be constrained to specific periods where the performance is important. You will therefore have to identify such pieces of code and control the GC in such a way that it gets a chance to return to its normal operations from time to time.

Regards

So, do the CPU utilization peaks correspond to GC collections, or not? I though you would create a chart showing how they correlate over the time.

Can you please first check whether these CPU peaks correlate with .NET garbage collections, using PerfMon? See e.g. blogs.msdn.microsoft.com/maoni/2004/06/03/gc-performance-counters/ , counters like

• “% Time in GC”
• “# Gen 0 Collections”
• “# Gen 1 Collections”
• “# Gen 2 Collections”

Thank you