WPF memory fragmentation
I have what I am assuming is a memory fragmentation issue.
We recently ported our WinForms application to a WPF application. There's some image processing that this application does, and that processing has always worked in the WinForms version of the application. We go to WPF and the processing dies. Debugging in a library has death at random points, but always with an array that has been stubbed, i.e. Distribution failure.
The actual processing is done in a C ++ library called by p / invoke and is fairly memory intensive; if the given image is N x M pixels large, then the image is N x M x 2 bytes (each pixel is unsigned and the image is gray scale). During processing, pyramids of images are created that are in floating point space, so the total memory usage will be N x M x (2 + 2 + 4 + 4 + 4 + 4), where the first 2 are input, the second 2 is output, the first 4 is the entrance to the floats, the second 4 is the level 0 difference display, and the last two quarters are the rest of the pyramid (since they are pyramids and each level is half the size in each direction, these 4s are the upper bounds). Thus, for a 5000x6000 image, 600 mb,which should fit into memory just fine.
(There is a possibility that using sort increases the memory requirement of other N x M x 4, i.e. input and output images on the C # side and then the same arrays copied to the C ++ side - could the sort requirement be larger ?)
How fragmented is WPF compared to WinForms? Is there a way to consolidate memory before starting this processing? I suspect that fragmentation is a problem due to the random nature of the faults when they occur, and that it is always a memory allocation issue.
Or should I avoid this problem entirely by running the processing as a separate process with data transfer over sockets or something similar?
a source to share
If I read this correctly, the memory allocation fails on the non-managed side, not the managed side. It seems strange then to blame WPF. I understand that you are making your conclusion based on "it worked in WinForms", but there are likely more changes than just that. You can use a tool like the .NET Memory Profiler to see the differences between how a WPF application and a WinForms application handle memory. You may find that your application is doing something you don't expect. :)
Per comment: Yes, I understand. If you're sure you've ruled out things like environment changes, I think you need to grab a copy of BoundsChecker and Memory Profiler (or DevPartner Studio ), and dig in and see what gets in the way of your memory allocation.
a source to share
I am assuming the GC is moving your memory. Try to commit memory on unmanaged ground while you have a raw pointer to an array and release it as soon as possible. Perhaps WPF makes the GC run more often, which explains why it happens to it more often, and if it's a GC, then that explains why it happens at random places in your code.
Edit: Out of curiosity, you could preallocate all your memory ahead of time (I can't see the code, so I don't know if this is possible), and make sure all your pointers are not -null, so that you can check that this is actually happening in memory allocation and not some other problem?
a source to share
It sounds like you want to be more careful about your memory management in general; i.e.: either run the processing engine in a separate address space that carefully manages memory, or pre-allocate a large enough chunk before the memory gets too fragmented and only manages images in that area. If you are using a shared address space with a .NET runtime in a lengthy process and you need large contiguous scopes, this will always potentially fail at some point. Just my 2c.
a source to share