0

I am using Perfview do analyse the performance of the Garbage collector.
I use the CLR Startup Flags: CONCURRENT_GC, SERVER_GC for my console app.
The slowness is sometimes in Gen 0, Gen 1 or Gen 2.
What would you suggest me to analyse this further?
I suspect that the GC is busy related to an external 3rd party lib which uses native code under the hood, but I would like to know how I can further analysis this.

enter image description here

weismat
  • 7,195
  • 3
  • 43
  • 58
  • 1
    `I suspect that the GC is busy related to an external 3rd party lib which uses native code` - the GC doesn't care/know much about native code's allocations. – Christian.K Jul 27 '17 at 14:56
  • 1
    why do you use Server_GC? – magicandre1981 Jul 27 '17 at 14:59
  • I also used client GC - the console program is more used as a service. One instances works fine for several hours until it hits the long pause. – weismat Jul 27 '17 at 15:01
  • What totally irritates me is that it is not Gen 2 which is slow, but also other generations. – weismat Jul 27 '17 at 15:03
  • 1
    https://blogs.msdn.microsoft.com/maoni/2015/08/12/gen2-free-list-changes-in-clr-4-6-gc/ – Hans Passant Jul 27 '17 at 17:09
  • try [.net 4.7.1](https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/) which brings GC improvements: *.NET Framework 4.7.1 brings in changes in Garbage Collection (GC) to improve the allocation performance, especially for Large Object Heap (LOH) allocations. This is due to an architectural change to split the heap’s allocation lock into 2, for Small Object Heap (SOH) and LOH. Applications that make a lot of LOH allocations, should see a reduction in allocation lock contention, and see better performance.* – magicandre1981 Oct 20 '17 at 13:31
  • have you tried .net 4.7.1? – magicandre1981 Oct 27 '17 at 14:00
  • trying since a few days and have not seen it so far. – weismat Oct 27 '17 at 14:02
  • so .net 4.7.1 fixes it? – magicandre1981 Oct 30 '17 at 17:13

0 Answers0