使用小图像(<= 4k像素数据)时,GC会被强制执行？

Question

当我处理小文件(<= 32x32)时,我看到性能计数器"#Indinal GC"(在一个完美的应用程序中应保持为零)迅速增加WriteableBitmap.

虽然这不是一个小应用程序内部的重大瓶颈,但是当内存中存在数千个对象时,它变成了一个非常大的问题(应用程序冻结在99.75%"GC中的时间",在每个步骤几秒钟)(例如:EntityFramework上下文加载了许多实体和关系).

综合测试:

var objectCountPressure = (
    from x in Enumerable.Range(65, 26)
    let root = new DirectoryInfo((char)x + ":\\")
    let subs = 
        from y in Enumerable.Range(0, 100 * IntPtr.Size)
        let sub =new {DI = new DirectoryInfo(Path.Combine(root.FullName, "sub" + y)), Parent = root}
        let files = from z in Enumerable.Range(0, 400) select new {FI = new FileInfo(Path.Combine(sub.DI.FullName, "file" + z)), Parent = sub}
        select new {sub, files = files.ToList()}
    select new {root, subs = subs.ToList()}
    ).ToList();

const int Size = 32;
Action<int> handler = threadnr => {
    Console.WriteLine(threadnr + " => " + Thread.CurrentThread.ManagedThreadId);
    for (int i = 0; i < 10000; i++)    {
        var wb = new WriteableBitmap(Size, Size, 96, 96, PixelFormats.Bgra32, null);
        wb.Lock();
        var stride = wb.BackBufferStride;
        var blocks = stride / sizeof(int);
        unsafe {
            var row = (byte*)wb.BackBuffer;
            for (int y = 0; y < wb.PixelHeight; y++, row += stride)
            {
                var start = (int*)row;
                for (int x = 0; x < blocks; x++, start++)
                    *start = i;
            }
        }
        wb.Unlock();
        wb.Freeze();     }
};
var sw = Stopwatch.StartNew();
Console.WriteLine("start: {0:n3} ms", sw.Elapsed.TotalMilliseconds);
Parallel.For(0, Environment.ProcessorCount, new ParallelOptions{MaxDegreeOfParallelism = Environment.ProcessorCount}, handler);
Console.WriteLine("stop : {0:n2} s", sw.Elapsed.TotalSeconds);

GC.KeepAlive(objectCountPressure);

我可以使用" const int Size = 48"十几次运行此测试:它总是在~1.5s内返回,"#Induced GC"有时会增加1或2.

当我将" const int Size = 48" 更改为" const int Size = 32"时,发生了非常非常糟糕的事情:"#Induced GC"每秒增加10点,整个运行时间现在超过一分钟:〜80秒![在带有8GB RAM的Win7x64 Core-i7-2600上测试// .NET 4.0.30319.237]

WTF!？

框架有一个非常糟糕的错误或我做了一些完全错误的事情.

顺便说一句:
我不是通过图像处理来解决这个问题,而是通过使用DataTemplate对一些数据库实体使用包含图像的工具提示:这个工作正常(快速)而RAM中没有很多对象 - 但是当存在大约数百万个其他对象(完全不相关),然后显示工具提示总是延迟几秒钟,而其他一切工作正常.

Answer 1

TL; DR:可能最好的解决方案是创建一个小池WriteableBitmaps并重用它们而不是创建它们并扔掉它们.

所以我开始使用WinDbg来探索导致集合发生的原因.

首先,我添加了一个调用Debugger.Break(),Main以便让事情变得更容易.我还添加了自己的调用GC.Collect()作为一个完整性检查,以确保我的断点工作正常.然后在WinDbg中:

0:000> .loadby sos clr
0:000> !bpmd mscorlib.dll System.GC.Collect
Found 3 methods in module 000007feee811000...
MethodDesc = 000007feee896cb0
Setting breakpoint: bp 000007FEEF20E0C0 [System.GC.Collect(Int32)]
MethodDesc = 000007feee896cc0
Setting breakpoint: bp 000007FEEF20DDD0 [System.GC.Collect()]
MethodDesc = 000007feee896cd0
Setting breakpoint: bp 000007FEEEB74A80 [System.GC.Collect(Int32, System.GCCollectionMode)]
Adding pending breakpoints...
0:000> g
Breakpoint 1 hit
mscorlib_ni+0x9fddd0:
000007fe`ef20ddd0 4154            push    r12
0:000> !clrstack
OS Thread Id: 0x49c (0)
Child SP         IP               Call Site
000000000014ed58 000007feef20ddd0 System.GC.Collect()
000000000014ed60 000007ff00140388 ConsoleApplication1.Program.Main(System.String[])

所以断点工作正常,但是当我让程序继续时,它再也没有被击中.似乎GC例程正在从更深层次的地方调用.接下来,我进入GC.Collect()函数,看看它在调用什么.为了更容易地做到这一点,我GC.Collect()在第一个之后立即添加了第二个电话并进入第二个电话.这避免了逐步完成所有JIT编译:

Breakpoint 1 hit
mscorlib_ni+0x9fddd0:
000007fe`ef20ddd0 4154            push    r12
0:000> p
mscorlib_ni+0x9fddd2:
000007fe`ef20ddd2 4155            push    r13
0:000> p
...
0:000> p
mscorlib_ni+0x9fde00:
000007fe`ef20de00 4c8b1d990b61ff  mov     r11,qword ptr [mscorlib_ni+0xe9a0 (000007fe`ee81e9a0)] ds:000007fe`ee81e9a0={clr!GCInterface::Collect (000007fe`eb976100)}

经过一番踩踏后,我注意到一个clr!GCInterface::Collect听起来很有希望的参考.不幸的是,它的断点从未触发过.进一步挖掘GC.Collect()我发现clr!WKS::GCHeap::GarbageCollect哪个被证明是真正的方法.关于此的断点揭示了触发集合的代码:

0:009> bp clr!WKS::GCHeap::GarbageCollect
0:009> g
Breakpoint 4 hit
clr!WKS::GCHeap::GarbageCollect:
000007fe`eb919490 488bc4          mov     rax,rsp
0:006> !clrstack
OS Thread Id: 0x954 (6)
Child SP         IP               Call Site
0000000000e4e708 000007feeb919490 [NDirectMethodFrameStandalone: 0000000000e4e708] System.GC._AddMemoryPressure(UInt64)
0000000000e4e6d0 000007feeeb9d4f7 System.GC.AddMemoryPressure(Int64)
0000000000e4e7a0 000007fee9259a4e System.Windows.Media.SafeMILHandle.UpdateEstimatedSize(Int64)
0000000000e4e7e0 000007fee9997b97 System.Windows.Media.Imaging.WriteableBitmap..ctor(Int32, Int32, Double, Double, System.Windows.Media.PixelFormat, System.Windows.Media.Imaging.BitmapPalette)
0000000000e4e8e0 000007ff00141f92 ConsoleApplication1.Program.<Main>b__c(Int32)

因此WriteableBitmap,构造函数间接调用GC.AddMemoryPressure,最终导致集合(顺便提一下,这GC.AddMemoryPressure是一种模拟内存使用的简单方法).这并不能解释从33到32的行为突然改变的行为.

ILSpy在这里提供帮助.特别是,如果您查看构造函数SafeMILHandleMemoryPressure(调用者SafeMILHandle.UpdateEstimatedSize),您将看到它仅GC.AddMemoryPressure在添加的压力<= 8192时使用.否则它使用自己的自定义系统来跟踪内存压力和触发集合.具有32位像素的32x32的位图大小属于此限制,因为WriteableBitmap估计内存使用为32*32*4*2(我不确定为什么有额外因子2).

总而言之,您看到的行为看起来就像是框架中的启发式结果,对您的案例而言效果不佳. 您可以通过创建比您需要更大尺寸或更大像素格式的位图来解决这个问题,以便估计位图的内存大小> 8192.

事后想想:我想这也表明由于GC.AddMemoryPressure#Induced GC 而被计入的集合被计算在内？

Answer 2

在所有SafeMILHandleMemoryPressure和SafeMILHandle无意义的情况下,调用方法on MS.Internal.MemoryPressure,它使用静态字段" _totalMemory"来跟踪WPF认为分配的内存量.当它达到(相当小的)极限时,诱导的GC开始并且永远不会结束.

你可以完全使用一点点反射魔法阻止WPF这样做; 只是设置_totalMemory为适当的负值,因此永远不会达到极限并且诱导的GC永远不会发生:

typeof(BitmapImage).Assembly.GetType("MS.Internal.MemoryPressure")
    .GetField("_totalMemory", BindingFlags.NonPublic | BindingFlags.Static)
    .SetValue(null, Int64.MinValue / 2);