PDFsharp & MigraDoc Foundation

Hey there,

I just started using this library. So far, it's been very simple to use, and the samples make learning quite easy.

One issue that I've noticed is that it doesn't seem to want to release the memory it uses. I understand that it holds the entire document in memory while creating, but I can't seem to find any way to release the memory, even after I'm done with the PdfDocument object. Calling Dispose(), either directly or via using statements, doesn't seem to work. Here's my code. It starts with a list of PictureViewModels (a custom class that holds information about images). For each image, it creates page and adds the image. GetNewPage(PdfDocument doc) is a method that gets a new page and sets the height and width of the page based upon some private properties.



Is there anything that I'm missing, or does this library never release used memory? Thanks for any help you might be able to offer.

Edit:

I just realized that I never mentioned how I knew it wasn't releasing memory. In the Task Manager, my program normally operates at around 80,000K Memory (Private Working Set). When I have my program use PDFSharp to create a report, the memory usage goes up and never comes back down. Each new PDF generated makes the memory usage go up. The larger the pdf file made, the more it goes up. If I ask it to generate a report with 500 images (resulting in a 250MB PDF), the memory usage jumps by 800,000K. The memory usage never goes back down.

Thanks again,

-Scott

Hi!

With our application, there is a significant increase in memory usage when we create the first document.
There are no significant changes of the memory usage when we create several other documents.

We use the WPF build, but IIRC it was the same while we used the GDI+ build.

Could this be a problem of "GetMedia()"?

See also:
viewtopic.php?f=2&t=832

_________________
Öhmesh Volta ("() => true")
PDFsharp Team Holiday Substitute

Hello again,

Thank you for your reply. Good thought, but GetMedia() just returns an enumeration of objects that have simple properties like the file name and image dimensions. I use it elsewhere without issue, and it's only when I start using PDFsharp that I start seeing large memory jumps.

I spent the weekend testing both builds and every scenario I could think of, and I've discovered something... The amount of memory my program reported after I used PDFsharp would remain constant, and was proportional to the size of the document created.

If I made a large document, my memory would stay around 800,000K. If I made a small document, it would stay around 100,000K. I assumed that the actual objects (PDFDocument, XImage, etc.) weren't being disposed, but I think that PDFSharp was just allocating itself enough memory to handle the last request.

If I made a large PDF, my memory would go up to 800,00K... and it would stay there until I made another PDF. If it was another large PDF, memory usage would remain constant... but here's the kicker... if I made a blank, single page document, memory usage would drop back down to just slightly higher than my normal operating memory usage.

In my original post, I was creating larger and larger PDFs, so I thought memory usage was climbing due to un-disposed objects, but it seems now that with each new PDF created, PDFsharp reassesses its memory footprint to be able to handle the new job. So long as I create a temporary small PDF after each job, my memory usage goes back to normal.

So, my new question to the developers is this: are my findings accurate, and if so, is there a cleaner way for me to reset the memory allocation without creating a dummy document? What I'm doing seems to work, but it feels like a hack.

Thanks again,

-Scott

Hi, Scott!
Your findings confirm that there is no serious memory leak with PDFsharp.
I have no idea whether .NET or your application keeps a reference to the most recently written file - but I don't think PDFsharp does.

Is memory usage a problem? Memory will be re-used when another file is being generated.

There was a problem with image files remaining locked when the WPF build was used. This was fixed with PDFsharp 1.50 beta and never occurred with he GDI build.
So far you didn't disclose which version you are using.

_________________
Regards
Thomas Hoevel
PDFsharp Team