Optimization vs. readability

It is not uncommon that I encounter situations, where I know the code I'm writing or refactoring is clearly not performance-optimal, and yet more readable.
Here's an example of code that I've encountered recently (excuse the bad formatting, I'm experimenting here):

struct State{  
float m_Prop1; 
  int m_Prop2;  
  std::string m_Prop3;
// ...
}

class Manager {      State oldState, newState; std::vector m_Elements; }
//... 

foreach elem in m_Elements {   

if (oldState.m_Prop1 != newState.m_Prop1) 

elem.SignalProp1Change(); 

else if (oldState.m_Prop2!=newState.m_Prop2) 

elem.SignalProp2Change();    

// ... 

}  

There are 2 ways to go from here. 

The first is to take the comparison outside the loop, as a result of which we only need to do the comparisons once. The second is to move both the comparison and the signaling into the elements, which would put all the important logic where it is actually needed. Here's the comparison.

	Performance-optimal version	OO version
Code in the Manager header	struct State {   m_Prop1, m_Prop2, m_Prop3; } class Manager {   State oldState, newState;   std::vector m_Elements; }	struct State {    m_Prop1, m_Prop2, m_Prop3; } class Manager {   State oldState, newState;   std::vector m_Elements; } or class ZState { friend class Element; private: m_Prop1, m_Prop2, m_Prop3; } class Manager {   ZState oldState, newState;   std::vector m_Elements; }
Code in the Manager	if (oldState.m_Prop1!=newState.m_Prop1)     foreach elem in m_Elements         elem.SignalProp1Change(); if (oldState.m_Prop2!=newState.m_Prop2)     foreach elem in m_Elements          elem.SignalProp2Change();	foreach elem in m_Elements    elem.SignalChanges(oldState, newState);
Code in the element source file	//nothing much happening here	void Element::SignalChanges(const State& oldState, const State& newState) {    if (oldState.m_Prop1 !=newState.m_Prop1)       SignalProp1Change();    if (oldState.m_Prop2 !=newState.m_Prop2)        SignalProp2Change(); }
Code in the element header file	class Element {   public:     void SignalProp1Change();     void SignalProp2Change(); }	class Element {  public:     void SignalChanges(const State& oldState, const State& newState);   private:     void SignalProp1Change();     void SignalProp2Change(); } or class IElement {  virtual void SignalChanges(const State& oldState, const State& newState) = 0; } class Element : public IElement { // the rest is the same as above }

The first solution is more performance optimal, since if a property hasn't changed, we never call any of the functions, thus skipping the traversal of the list altogether. In the second solution is more modular, and all logic is moved into the elements. This way we hide all that logic from the manager, we can also hide the contents of the state from the manager. This latter approach is more robust, leaving the manager class completely oblivious to logic of the elements. Also a new programmer looking at the code base needs to inspect less code in order to figure out what to do. 

So what to do, what to do? I typically prefer the second option, as you may have already guessed. The benefits of modularization are great for maintenance, and the performance gain may only be important if this code is executed very frequently. But I think this example does illustrate an important point. Data hiding can prevent us from getting code that is fully performance-optimized. The more we separate code into clean independent modules, the less we can take advantage of their interdependence.