I was doing some profiling of my web app that uses PDFsharp w/ GDI+ and found that StringFormat objects were being created at a very high frequency. In my case, 3 megabytes worth of such objects in just a few seconds, swamping all other objects by an order of magnitude. They weren't leaking, but they did incur a high GC cost.
Digging into the PDFsharp code it seems that any call to DrawString or MeasureString that does not supply an XStringFormat results in a call to one of the XStringFormats accessors, which creates a new XStringFormat and backing StringFormat object. Further, internally many methods call the short forms of MeasureString (e.g. XTextFormatter.Font), leading to many allocations even when the caller is supplying an XStringFormat to all calls that accept them.
To mitigate this, I changed the XStringFormats members to initialize static readonly properties instead of having the accessors create new instances each time. These XStringFormat objects could be mutated so this wouldn't be a general purpose fix, but there's probably some approach that would eliminate all of these allocations.
|