Join Simon Allardice for an in-depth discussion in this video Rule 1: Code efficiency, part of Foundations of Programming: Code Efficiency.
You maybe familiar with the phase first, do no harm. Sometimes, attributed to the Hippocratic Oath from 500 BC or there about, but a fundamental principal of medical ethics. First, don't make it worse. There maybe a medical problem but if we just dive in, however pure our intentions, we risk making things worse. So, responsibility number one in medical ethics is don't do that. We would be wise to keep that idea in mind.
So, what I'm going to call my personal rule number one of working on code efficiency, first, do nothing. Okay, this course isn't going to be very long if I successfully persuade you to do nothing every time, but notice the way that I'm phrasing this. First, do nothing, first do no harm. So, a problem has presented itself, some kind of efficiency issue, performance issue, responsiveness issue. Just stop for a moment. Leave the code alone.
Don't assume you know how to fix it or where to go to fix it. We're trying not to jump to conclusions. We are going to work on efficiency, but first we need to pause so we can understand what the problem really is. Now, if your immediate reaction is, well I can't do nothing. I have to do something now. I have an application that's crashing. We are having very different conversations. If your code is crashing on any kind of repeatable basis, efficiency is not your primary concern. Your first order of business is to get the code working at all before you worry about it working efficiently or optimally.
Now you might debate the word here. You might hear something like oh, the program is crashing because of inefficient use of memory. Well again, if this is happening on any kind of regular basis, that's more ineffective or unreliable or even unacceptable use of memory, rather than inefficient. Now that's a different problem. That's a repeatable bug, and that needs fixed before you ask these efficiency questions. If there are errors in the logic, we don't fix anything by just making those errors run faster.
So we might be improving our application but we are not bug fixing here. That's not the focus. Now if we're working on optimizing existing code, and we usually are working on existing code for reasons I will cover in a moment, the precondition for working on efficiency is that the code already works. And that we first do nothing. We need to stop so we can understand where the problem really is.
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