10

Due to seemingly-premature Out of Memory exceptions, we have been examining closely the memory usage of various .NET constructs... particularly large objects that tend to fragment the Large Object Heap, causing premature Out of Memory exceptions. One area that has been a bit surprising is the .NET Image classes: Bitmap and Metafile.

Here's what we think we have learned, but have been unable to find MS documentation to verify, so we would appreciate any confirmation others can give:

(1) When you create a Bitmap object from a compressed raster file (JPG, PNG, GIF, etc), it consumes memory for a fully uncompressed pixel array, at the full resolution of that file. So, for example, a 5MB JPG that is 9000x3000 pixels would be expanded into 9000x3000x3 bytes (assuming 24bit color, no alpha), or 81MB of memory consumed. Correct?

(1a) There's some evidence (see 2b below) that it ALSO stores the original compressed format... so, actually 86MB in this case. But that's unclear... does anyone know?

(2) When you create a Metafile object and then draw a raster file (JPG, PNG, GIF, etc) into it, it only consumes memory for the compressed file. So, if you draw a 5MB JPG that is 9000x3000 pixels into a Metafile, it will only consume roughly 5MB of memory. Correct?

(2a) To draw a raster file into a Metafile object, the only way seems to be to load a Bitmap with the file and then draw the Bitmap into the Metafile. Is there a better way that doesn't involve temporarily loading that huge Bitmap data (and causing the associated memory fragmentation)?

(2b) When you draw a Bitmap into a Metafile, it uses a compressed format of size similar to the original compressed file. Does it do that by storing the original compressed file in the Bitmap? Or does it do it by re-compressing the expanded Bitmap using the original compression settings?

(3) We originally assumed that large (>85KB) Image objects would be placed in the Large Object Heap. In fact, that seems to NOT be the case. Rather, each Bitmap and each Metafile is a 24-byte object in the Small Object Heap that refers to a block of Native Memory that contains the real data. Correct?

(3a) We assume such Native Memory is like Large Object Heap in that it cannot be compacted... once the big object is laid into Native Memory, it will never be moved, and thus fragmentation of Native Memory can cause as many problems as fragmentation of Large Object Heap. True? Or is there special handling of the underlying Bitmap / Metafile data that is more efficient?

(3b) So, there seems to be four independent blocks of memory that are managed separately, and running out of each can result in the same Out of Memory exceptions: Small Object Heap (managed objects < 85KB, compacted by the GC), Large Object Heap (managed objects > 85KB that are collected by GC, but not compacted), Native Memory (unmanaged objects, presumably not compacted), and Desktop Heap (where windows handles and such limited resources are managed). Have I documented those four properly? Are there others we should be aware of?

Any clarity that anybody can provide on the above would be greatly appreciated. If there is a good book or article that fully explains the above, please let me know. (I am happy to do the required reading; but the vast majority of books don't get that deep, and thus don't tell me anything I don't already know.)

Thanks!

Brian Kennedy
  • 3,499
  • 3
  • 21
  • 27
  • 1
    GDI+ stores image data in unmanaged memory. So none of your assumptions are close. Forgetting to dispose bitmaps is a quick way to hit OOM. Address space fragmentation is another one, a 32-bit process reaches 90 MB as the danger zone after a while. – Hans Passant Mar 20 '13 at 17:17
  • "none of your assumptions are close"?? But everything you say around that is consistent with my assumptions above... so, not sure what you're telling me. Are you saying that "Native Memory" is different than "unmanaged memory"? Or did you mean "all of your assumptions are close"?? – Brian Kennedy Mar 20 '13 at 18:00
  • On 2(a), the best I have come up with so far is "No, but Yes sorta...": Create a separate .exe that simply reads in any given raster file into a Bitmap and then opens a new Metafile file on disk and does DrawImage of that Bitmap into that Metafile and quits. Then in my main app, when the user points me to a raster file, rather than opening it and generating memory fragmentation in my main app, I invoke that .exe to create a temporary file containing a Metafile, and then in my main app I read in that file directly to a Metafile. Clunky, but no memory impact on my main app. Any better ideas? – Brian Kennedy Mar 29 '13 at 13:45

2 Answers2

4

There are two ways to store image data: as pixels, or as vectors. Bitmap is about pixels, Metafile is about pixels and vectors. Vector data is a lot more efficient to store.

To allow manipulation of bitmaps, their data must be stored uncompressed in memory. Otherwise GetPixel and SetPixel would have to uncompress, change, recompress the bitmap for every change (if that would be even possible to begin with).

Metafiles were created by Microsoft and intended to work with GDI, so it might incorporate some more memory efficient compression algorithms that work directly with the graphics card. Also, there are no GetPixel SetPixel methods for metafiles, so it does not have to be uncompressed in memory to allow manipulation.

You should not have to care about the memory pools that the runtime uses. There are way more, and the runtime decides where it puts objects. Also, you should not care about out-of-memory exceptions that may possibly arise from using (large) objects. The runtime will do all it can (putting objects in gaps between other objects, compacting heaps, expanding available virtual memory) to ensure you won't get an out-of-memory exception. If you somehow do get such an exception, there is probably another problem in your code that should be fixed (such as a memory leak).

An overview of the memory heaps, maps and tables: (source)

Heaps, maps and tables used in .NET

Also, your assumption that objects of over 85 KiB are placed on the Large Object Heap is not entirely correct. Is is correct for most objects in the current version of the CLR, but for example an 8 KiB array of doubles (1000 doubles) is also allocated on the Large Object Heap. Just let the runtime concern itself with this.

Community
  • 1
  • 1
Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157
  • Unfortunately, "just let the runtime concern itself with this" only works for small object heap. We are using memory profilers... we have no leaks... yet we can run out of 2GB of memory managing a single document that shouldn't be more than about 10MB of data. How? Fragmentation. Redesigning to minimize fragmentation has gotten us up to 50MB... and then up to 100MB... and we are continuing that effort. So, unfortunately, due to fragmentation, we MUST concern ourselves with this. (Thanks for the source link where you pulled that pic... very good info there.) – Brian Kennedy Mar 20 '13 at 17:56
  • @BrianKennedy I have no idea what you are doing, but you have some options. Free your images as soon as you're done with them (null all pointers, ask the GC to collect memory). You could use C++/CLI to manage the memory for your images yourself. You could look into methods that load only the part of the image that you need to manipulate, or methods that load the image in their compressed format and do what you want (display it or something). – Daniel A.A. Pelsmaeker Mar 20 '13 at 18:42
  • Yes, Virtlink, it appears I can use Metafile instead of Bitmap to avoid the uncompressed images. Unfortunately, it seems the only way to get a JPG into a Metafile is through a Bitmap... although I can Dispose it immediately to free that memory, it will still result in fragmentation of the memory (it seems). Hence my questions above. – Brian Kennedy Mar 20 '13 at 19:12
2

I know the answers to some of these:

(1) Yes, that is the definition of a Bitmap image.

(3) Yes, that is why Bitmap implements the IDisposable interface.

(3a) That seems surprising. Are you running the Dispose() method on your Bitmap objects when you are done with them?

(3b) At least those four, yes.

Pieter Geerkens
  • 11,775
  • 2
  • 32
  • 52
  • This is definitely the first thing to check, for example see [this](http://stackoverflow.com/questions/8830770/why-is-there-a-memory-leak-when-i-do-not-dispose-bitmaps-that-i-save-to-a) post – bigge Mar 20 '13 at 17:40
  • Yes, our Image objects are being disposed properly. We are running memory profilers... there are no leaks. – Brian Kennedy Mar 20 '13 at 17:51