I’m classically trained psychologist, not a programmer, so sometimes the more advanced aspects of programming escape me, in particular regarding program efficiency and/or certain best practices, in this case with regard to the use of variables.
Here is some pseudo-code:
var a;
var b;
var c;
function GetSomeInformation() {
returns "XYZ";
}
a = GetSomeInformation();
b = GetSomeInformation();
c = GetSomeInformation();
So my question is:
Is it more or less efficient (or the same) to store data into a variable once and reference that as opposed to repeated calls to the same function?
I.E., is this code more efficient?
var results = GetSomeInformation();
a = results;
b = results;
c = results;
If so, is this gain or loss in efficiency generally the same across languages, or does it vary by language? Are there thresholds where it becomes better to name a variable as opposed to using a repeated function call or vice versa? What aspects might change its efficiency (e.g., is there a difference whether it’s a member function of a class vs. a regular function in the global scope)? etc.
If possible, I’d like to know specifically how such a notion applies to C++/MFC dialogs, as it arose when I was writing some code in that framework.
// define pointers to the items in my form
CListBox *pLISTBOX = (CListBox*) GetDlgItem(LISTBOX);
CStatic *pSTATIC_A = (CStatic*) GetDlgItem(STATIC_A);
CStatic *pSTATIC_B = (CStatic*) GetDlgItem(STATIC_B);
CEdit *pEDIT_BOX_A = (CEdit*) GetDlgItem(EDIT_BOX_A);
CEdit *pEDIT_BOX_B = (CEdit*) GetDlgItem(EDIT_BOX_B);
int SelectedIndex = pLISTBOX->GetCurSel();
pSTATIC_A->SetWindowText(pLISTBOX->GetItemData(SelectedIndex));
pSTATIC_B->SetWindowText(pLISTBOX->GetItemData(SelectedIndex));
pEDIT_BOX_A->SetWindowText(pLISTBOX->GetItemData(SelectedIndex));
pEDIT_BOX_B->SetWindowText(pLISTBOX->GetItemData(SelectedIndex));
To answer your question: It is generally more efficient to store data in a variable and reference that. Additional local variables are cheap.
Starting with a simple example, suppose you have the code fragment:
x = 5;
y = x*x + 1;
z = x*x + 2;
If you look at the above code and pretend you’re the CPU executing it step by step, the CPU would do the multiplication twice with the same value of x. That’s almost always less efficient than doing the multiplication once:
x = 5;
x2 = x*x;
y = x2 + 1;
z = x2 + 2;
Now, modern compilers almost always have an optimisation called common subexpression elimination, which will have the same effect of extracting x2 as in the above example. So you often don’t have to worry about it, because the compiler has your back.
Having said that, using a variable such as x2 might substantially reduce the complexity of the following lines, so there’s nothing wrong with introducing a variable like that for readability reasons.
In the case of your MFC code, you are repeatedly calling pLISTBOX->GetItemData(SelectedIndex). Since this is a function call that makes a call into the OS to get further data, the compiler can’t do common subexpression elimination on that. Instead, I would introduce a new variable so you only have to do the call once:
int SelectedIndex = pLISTBOX->GetCurSel();
const char *data = pLISTBOX->GetItemData(SelectedIndex);
pSTATIC_A->SetWindowText(data);
pSTATIC_B->SetWindowText(data);
pEDIT_BOX_A->SetWindowText(data);
pEDIT_BOX_B->SetWindowText(data);
2
- Yes, the second code is marginally more efficient than the first code, in most languages.
- It probably doesn’t make any practical difference.
- It probably does make a difference in readability, so go with the cleaner code.
Also, a good compiler (including Java’s JIT) will inline repeated method calls and cache repeatedly used values, so the two examples would probably end up performing comparably.
Reference the following rules of thumb:
Make it work, make it right, make it fast… in that order. – Kent Beck
The First Rule Of Optimization: Don’t.
The Second Rule Of Optimization: Don’t… yet.
The Third Rule of Optimization: Profile Before Optimizing
Premature Optimization is the root of all evil. – Donald Knuth
In most cases, >90% of your program’s time will be spent in <10% of the code, and without profiling your code, you have no idea which 10% that is. So don’t even worry about it until you get feedback; it’s much more valuable to optimize for programmer time than run time.
It is usually more efficient to store a computed value in a local variable, assuming your compiler didn’t already optimize that for you. In fact, sometimes this is built into a function itself, in a technique called memoization.
However, most of the time, the efficiency gain is small enough to be considered negligible. Readability should usually be your primary concern after correctness.
That being said, using a local variable also often happens to make it more readable, giving you the best of both worlds. Using your example:
const char* text = pLISTBOX->GetItemData(SelectedIndex);
pSTATIC_A->SetWindowText(text);
pSTATIC_B->SetWindowText(text);
pEDIT_BOX_A->SetWindowText(text);
pEDIT_BOX_B->SetWindowText(text);
This is much more clear to a human reader. Not only do you not have to read that long function call on every line, it is explicitly clear that all the widgets are receiving the exact same text.
Variables are essentially free, but the function call has an unknown cost, so always go with the variable.
A general principle I follow is that if I don’t know how a function is implemented, it might be expensive and if I know that I only need the value from that function once, I just store it locally. Your code example would then become:
// define pointers to the items in my form
//...
int SelectedIndex = pLISTBOX->GetCurSel();
String text = pLISTBOX->GetItemData(SelectedIndex); //Ok, so maybe String isn't a valid type here but you get the idea...
pSTATIC_A->SetWindowText(text);
pSTATIC_B->SetWindowText(text);
pEDIT_BOX_A->SetWindowText(text);
pEDIT_BOX_B->SetWindowText(text);