This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it
Thus-far we've talked about core infrastructural and social needs for a project, such as knowing what you want to do and why you want to do it, ensuring you keep track of what you did, and ensuring you won't lose it if the worst happens. We've also talked about verifying that what you've done actually works, so today let's talk about knowing how well it works.
The desire to make something faster, smaller, more efficient, is a common failing among programmers. Yes; I did say "failing". It's a failing because for the most part, programmers don't actually know for certain that what they want to make better is worth their time to do so. Of course, you might have a goal of making something more efficient as an exercise in optimisation, or making something more capable as an exercise in increasing the functionality of a piece of software; but for the most part these efforts are usually premature because programmers really love to work on the code and very rarely do they actually want to step back and measure.
It's not always possible to measure objectively the level of functionality of a piece of code. There's always extra things you can think of which it "would be nice to have" but if you can't point at a need to have them, a requirement if you will, then perhaps you don't need them. Making something faster is only worth doing if what you have now does not meet some requirement for rapidity. So let's assume for a moment that you know that your program needs to go faster to meet a requirement; how do you determine where to focus your efforts?
There are a number of pieces of software out there to help you. Typically they are called profilers and exist at many levels. If your software is in a dynamic language such as Python or Lua, there'll be profilers at the language level for you to use. If on the other hand your software is written in something lower level such as C, there are profilers which work at the machine level to give you a deep understanding of where time is being spent in your code. Ultimately it's important to realise that without using tools such as profilers, to measure where time is being spent in your software, you will never be able to focus your efforts effectively on improving its performance.
A week or so ago, at work, I was looking at something I was convinced ought to be faster than it was. I ran several sets of tests through the software using a profiler and discovered that something I had previously assumed about the software was wrong. The profile led me to see that an operation I was convinced was being cached actually wasn't, and four extra lines of code later (four in a codebase of thousands and thousands) we had taken the complexity of a piece of code from O(nm) to O(n). Without that profiling effort, I'd have been looking in completely the wrong place for the quick fix to improve our performance.
Your homework for this week is to play with measuring the performance of a project of yours which perhaps doesn't behave as well as you'd hoped. Perhaps if you profile it well, you'll find a quick fix which will give you the satisfaction I got from writing those four lines of code. If all your own software is perfect (or meets its requirements at least) then why not look for something else to profile. You might be able to make a useful contribution to an open source project if you look hard enough. Remember that a useful contribution to a project could simply be the work to get the profiles made and the trouble spots isolated, even if you have no idea how to fix them yourself.