Posted on May 20th, 2005 by Kevin Dangoor

Performance improvements in unreleased products

There’s the old question “if a tree falls and no one hears it, did it make a noise?” Just as goofy: “if you improve the performance of an unreleased application, did it actually get faster?”

I’m definitely in the “premature optimization is the root of all evil” camp, but the time has come for some performance work on Zesty News. I currently have well over 1,000 unread items, and it takes a few seconds to bring up the main view. Fixing this does make the code more complex, which is why I’m glad I didn’t do it prematurely But, now is the time. So, I’ll see the performance difference. Zesty’s alpha testers won’t even be aware that it used to take a few seconds. (And that’s the way it should be.)

3 Responses to “Performance improvements in unreleased products”

Ian on May 20th, 2005 9:34 am:

Yeah, I go back and forth on this but sometime you just need to do it now. I just spent the past day optimizing a major part of the queue/filter system in HelpSpot. By adjusting how I handled a particular situation I lowered the number of DB queries from potentially dozens to 2. Which seemed worthy of taking the extra time up front. I think it’s worth doing now if it’s a core part of your product like this was for me or as item display is for Zesty.

Brian F. on May 23rd, 2005 2:31 pm:

Well, I suspect that you have the test coverage to be confident that your speed improvements are not breaking anything either.

Brian F.

Kevin Dangoor on May 24th, 2005 7:26 am:

In this particular area of Zesty News, my test coverage is indeed pretty good. My philosophy has been to take a pragmatic approach to testing (I think you probably know that I work that way): Do automated tests as much as is practical, and isolate anything that is not getting automated tests. “Practical”, for testing purposes, means weighing the difficulty (ie cost) of making a test vs. the risk of not having one (ie the benefit).

Right now, there are two areas that are not tested automatically: the networking stuff (feed retrieval) and the JavaScript for the UI. The networking stuff *did* have tests at one point, but I was running into some test framework issues. Those tests will likely return in some form. Assuming Selenium works as advertised, I will likely start having tests for the JavaScript as well.