Join Simon Allardice for an in-depth discussion in this video Clearing up the misconceptions, part of Foundations of Programming: Code Efficiency.
When I talk to developers about working on efficiency and optimization of applications, and if they haven't done this kind of work before, they're often intimidated by it and I will hear the same two misconceptions, two totally understandable but thankful incorrect assumptions about what this work really involves. First, that improving the efficiency of an application is going to be something like copy editing the manuscript of a badly written novel, or a technical training manual. So if this represented our application, we're going to have to go through this entire thing line by line with red pen and highlighter attempting to tweak and improve every tiny part of it.
Trying to squeeze every last ounce of improvement out of every single line. No, this is rarely, if ever necessary. Because the likelihood is that even in a large application there is just a handful of places in here. Sometimes even just one, that you really need to deal with. And if you find, and improve, those places, what you can do there will objectively beat into insignificance, every other possible improvement you could make to the rest of the program.
But there's the question, where are those places? Well before we get to finding those, let me deal with the second misconception. That working on efficiency always requires us to have, guru level knowledge of the language and environment. That we're secretly worried that the problem is going to end up being that we used the straight forward classes and methods we learned in the first few weeks with the language. And some performance hipster is going to come along and sneer at us and say, oh you're still using the string class, well nobody actually uses the string class, that's just for noobs.
And we're going to have to replace everything with a collection of of obscure methods buried in complex classes in some esoteric framework we never even heard of before. Again. Now, huge improvements are achievable with code we could've written in our first few weeks, or even days, with the language. Now you get those two misconceptions out of the way, and you realize that efficiency is not some black art, that only experts can achieve. It's something all developers can work on. Now, are there advanced and very specific improvements you can make if you are an expert? Well, of course, having more options is never a bad thing.
But, being an expert is not necessary. And in one way may even be detrimental because the attitude we should bring to the first steps of this is one of humility, not a word easily associated with software developers. But, as we'll see, one that can be very useful.
Learn to choose the right data types, understand the pitfalls of using high-level languages, and decide where to spend your time. Plus, see how the underlying memory management model may have more of an impact than you realize, and what performance issues you can expect working with databases and web services.
- Identifying problems in the code
- Embracing constraints
- Using code analysis tools to measure performance
- Managing memory
- Managing disk-based and network resources