// Internet Duct Tape

Programming Best Practices: Profiling

Posted in Firefox and Greasemonkey, Programming and Software Development, Technology by engtech on November 14, 2007

Programming Tips

My first task coming back from my work stress blogging hiatus is to finally fix problems with Akismet Auntie Spam that Lorelle reported over a month ago — if your Akismet spambox has over 10,000 spam comments then Auntie Spam is going to crash hard. Viewing that many comments at once will make Firefox use eight times more memory than normal web browsing, even without using Auntie Spam [1].
This means it’s time to do some code profiling [2]. In programming, profiling means to measure your code and find out which parts are using the most time and the most memory. Profiling gives you performance analysis measurements so that you can optimize your program for speed and/or memory.

“Don’t prematurely optimize” is a programming Best Practice, and it can be summed up in the words of my grandfather: “measure twice and cut once”. You can guess at what parts need fixing, but it is much more effective to measure how your program performs so that you can focus on the worst parts. They have the most room for improvement. Without profiling you could easily spend several hours optimizing a loop that executes in negligible time and ignore the three lines that copy huge chunks of memory for No Apparent Reason. Get it working, and then use your profiler to get it working fast.

Profiling is a Skill

I’ve been creating Greasemonkey scripts using javascript for a year now, and this is my first time firing up any kind of javascript profiler. It really struck me that I waited too long to do this. Don’t prematurely optimize, but also don’t waste any time learning how to run a profiler on your code and interpret the results. If you’ve never gone through the process of optimizing code in a language you regularly use, then you’ve been relying on all kinds of bad habits [3]. Learn how to integrate a profiler with your program as soon as possible so that performance analysis doesn’t become one of those “I’ll get around to it” tasks that never happens.

Another good rule is to always test with large data sets. Ideally you want a fast case for rapid prototyping of new features, and a worst case for stressful testing of that new feature. To often we use small sets of data for development and testing. We never realize how badly our code performs in real world conditions. Speed and responsiveness play a greater factor in whether or not someone becomes a regular user of your program than you might realize.


[1] One thing WordPress does wrong is it includes all of your comment spam in their WordPress export files. One friend saw his export file decrease from 83 MB to 8 MB once he deleted the comment spam.

[2] The best way to profile Javascript is with FireBug, but it doesn’t recognize Greasemonkey scripts unless you embed them in the page so FireBug can find them. Wikipedia has a list of profilers for popular languages.

[3] Some of the bad habits that were lurking in Auntie Spam:

  • I was using a custom getElementsByClassName instead of an XPATH call. XPATH can be so much faster that walking the DOM.
  • I had too many innerHTML assignments instead of leaving HTML as a string and then giving it to the web page to process as a final step
  • Inefficient regular expressions
  • Too many copies of the comments in memory