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 ;)
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