Hi nether ^_^
Very good question.
I will say that, with only few exceptions, when at the end you need the urge to change (restructure) somehting, it's the sign that you went the wrong way somewhere and end up in that situation. And it can happen to anybody anytime.
Do you know agile development ?
For example, in TDD, we use a cycle that is short enough for you to see the final end result of your code... it's a principle you may want to experiment : consider your code as a final product at each step of your modification and consider yourself in a situation where you will always have to deploy.
You'll then do your best, the most valuable functionalities sooner and before the others and relie on refactoring to improve your code.
When a "big" refactoring is "needed", probably you'll want to do it as soon as possibly (it's a principle that states "do the hard things sooner").
But big refactoring occurs in "bad" codes.
Then you talk about efficiency.. this is an other story ^_^ and a very important one for C++ programmers as us.
And your feeling is right, optimization must always come at the end. And yes, you sometimes have a lot to modify for that.
Sometimes you will find yourself stuck in an architecture you've created, it was good months ago, now, no more. It happens also... change it if it's required.
Other optimizations are rarely so "destructive" and only impact one or few functions.
Rule of thumbs : always, perpetually refactor (all the time). But optimize at the final end when your program is finished.
Readibility, robustness first. Then efficiency ;o)
FuryGuy, I would add an other step to the refactoring :
void dump(... container)
for(auto const& e : container)