When Commented Out Code Attacks

AKA: a Teachable Moment in Performance Tests, Profilers, and Debugging statements. The other night I couldn't sleep, so I started to write some code. Most great programming insights begin like this. I added some new CSS selector types to the Amino skinning parser, then went to bed. A couple of days later I noticed Leonardo, the drawing program built on Amino, was running visibly slower. Clearly I had screwed something up with my recent changes. Time to put on the work boots and dig in. It has been said: the only way to make your code faster is to never let it get slower. And the only way to do that is to create performance tests that you can run on both the old and new versions of your code. Fortunately I started adding configurable tests a month ago, letting me run a layout test on any revision I choose and compare it to any other revision. By running the test on the last several versions I could narrow down exactly which commit had caused the problem. Easy enough. Now I can fix the problem. Or so I thought... Once isolated, I quickly deduced my CSS evaluator was doing extra work looking for parent nodes that don't matter in most cases. I simply commented out the extra function, then ran the performance test again. Hmm. It's still slow! But I turned off all of the functional changes, right? After analyzing this code for two hours I gave up doing it by hand and pulled out a real profiler. Never guess where yo...

Date: November, 05 2010
Url: http://www.java.net/blog/joshy/archive/2010/11/05/when-commented-out-code-attacks

Others News