Cross-posted from Softartisans
Performance is a widely overlooked feature in the development world. In enterprise development, better performance can correlate directly to company profit. More efficient programs utilize fewer resources; fewer resources cost less money.
On the consumer end, performance can make or break a product. One reason Google has such great market share is the speed at which they deliver their applications and data. The philosophy is pretty simple really: when users have to wait for something, they either get distracted (in which case they forget about you) or frustrated (in which case they’re mad at you).
The bottom line is performance matters. That’s why performance testing is vital to any product and company.
Steve Souders is the head performance engineer at Google and has literally written THE book on web performance. I’ve been on Steve’s RSS feed now for a few years and the lessons and data he presents really seem to stick with me long after I’ve read the post.
The obvious use case for profilers like dotTrace is to profile your application when you’ve noticed that something is running much slower than you think it should. However, it’s also good to simply profile your application from time-to-time and see if anything sticks out or has changed significantly. Maybe you’ll realize that one of your arrays would be better suited as a dictionary, or that you’re duplicating efforts in some parts of your code.
At SoftArtisans we use NUnit a LOT. Performance testing is just a small part of that, but by testing performance with NUnit every time we build, we can get a lot of interesting data that shows how performance related to different tasks has changed over time. This gives us the ability to quickly detect and address changes that might have dramatic effects on performance.
For sifting through and analyzing all of our performance data that’s generated by NUnit, I look towards the Math.Net Numerics library. It’s got a bunch of great statistics functionality built in with which I can slice up the data. I then usually throw the end result into Excel (using OfficeWriter of course) for visualization of the data and generating nice charts that I can play around with.
Those are just a few of the resources available to you when you’re beginning your performance testing. I’d love to hear what others are using or have found useful in the past. Let me know in the comments section.