Profiling a few Windows Forms PDF viewers

Lunch blog post, typos might occur as I’m balancing a sandwich in one hand and typing with the other ;) Back from Utah (Pluralsight author summit 2015) and although I was only there for three days I’ve managed to avoid getting jet lagged both ways with 9h time difference, woohoo! I had told myself no commits this week, jokingly expecting to be wrecked but I’m actually doing fine. I’ll post some pictures later this week, but here is one with some of the awesome staff at Pluralsight. You should see the one where we made a human pyramid haha! Later ;)

The client I’m currently at has PDF rendering as a part of their finance system and we needed to evaluate if we should replace the PDF rendering component in the windows forms application. Although the components are evaluated on several factors (such as license and price) memory and load time was in particular important. I ended up testing several products and I thought I’d share the results with you. As always, keep in mind that accuracy is hard to achieve and I’ll cover some of the problems below. I tested two versions of GDPicture DocumentVieware, 8 which is the current version we are using and 11 the latest version to see if an upgrade would be worth it. Our of the three products this is the most expensive one, and even with an upgrade the price is a almost 5 times higher than alternatives. This is also because GDPicture is the most feature dense and also allows us to manipulate PDFs and convert basically any document to a PDF, as well as supports old PDF formats. However there are open source alternatives to manipulating PDFs such as iTextSharp (be aware of license cost for closed source commercial products) and PDFSharp (MIT lic) and therefore we decided to consider less feature packed components.

For memory consumption I used the memory profiler (and noticed some vendors have poor memory management and it’s easy to end up with memory leaks), for performance I used the stopwatch in the diagnostics namespace which I’m sure you understand isn’t 100% accurate. A problem with that was testing the Telerik PDF control as the document loaded is triggered when the document is loaded and not rendered, and the rendering takes an extra 4 seconds. I therefore did some manual testing by video recording load times and then using the video to get the load times. A large PDF (30MB) was used, which contained several images (a book by Microsoft Press).

Each test was performed 10 times and what you see is the average, testing both initial load time for the first file, as well as the second. I also compared using a bytestream or file path on some of the components as difference was significant for some of them. The demo code was a simple Windows Form window with just a button and the PDF viewer, with no configurations.

Although by far not a perfect test, here are the results for memory and load times:

Comments

Last modified on 2015-03-04