Leistungsunterschied zwischen ++ Iterator und Iterator ++?

Question

Mein Arbeitskollege behauptet, dass für Objekttypen Vorinkrement effizienter ist als Post-Inkrement

z.B.

std::vector<std::string> vec; 

... insert a whole bunch of strings into vec ... 

// iterate over and do stuff with vec. Is this more efficient than the next 
// loop? 
std::vector<std::string>::iterator it; 
for (it = vec.begin(); it != vec.end(); ++it){ 

} 

// iterate over and do stuff with vec. Is this less efficient than the previous loop? 
std::vector<std::string>::iterator it; 
for (it = vec.begin(); it != vec.end(); it++){ 

} 

Answer 1

Postinkrement muss den Wert zurückgeben der Iterator hatte, bevor es Inkrementieren war; Der vorherige Wert muss also irgendwo kopiert werden, bevor er mit dem richtigen Inkrement geändert wird. Die zusätzliche Arbeit kann ein wenig oder viel sein, aber sie kann sicherlich nicht weniger als Null sein, verglichen mit einer Vorinkrementierung, die einfach die Inkrementierung durchführen und dann den gerade geänderten Wert zurückgeben kann - kein Kopieren // Speichern // usw. notwendig.

Also, es sei denn, Sie müssen POSITINCREMEN ausdrücklich haben (weil Sie den "Wert vor Inkrement" in irgendeiner Weise verwenden), sollten Sie stattdessen immer preincrement verwenden.

Answer 2

haben einen Blick auf diese http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=171881

Answer 3

Für primitive Typen, habe ich dies zu tun. Es hat mir 1998/1999 in vielen Programmen von Visual Studio eine Steigerung von 10% gebracht. Kurz darauf haben sie ihren Optimierer repariert. Der Post-Inkrement-Operator hat eine Variable auf dem Stapel erstellt, den Wert kopiert, die Quelle inkrementiert und anschließend die Variable aus dem Stapel entfernt. Sobald die Optimierer erkannt hatten, dass sie nicht verwendet wurde, ging der Nutzen verloren.

Die meisten Leute hörten nicht auf diese Weise zu codieren. :) Es hat ein paar Jahre gedauert.

Für Objekte bin ich mir nicht sicher, wie das funktionieren würde. Ich nehme an, dass ein Kopieroperator für eine echte Implementierung von Post-Inkrementen erforderlich wäre. Es müsste eine Kopie erstellen und die Kopie für die Operationen verwenden und die Quelle erhöhen.

Jacob

Answer 4

Die Standardinkrement Betreiber wie folgt aussehen:

class X 
{ 
    X operator++(int) // Post increment 
    { 
     X tmp(*this); 
     this->operator++(); // Call pre-increment on this. 
     return tmp; 
    } 
    X& operator++() // Pre increment 
    { 
     // Do operation for increment. 
     return *this; 
    } 
}; 

Beachten Sie die Post-Inkrement wird in Bezug auf die Pre-Inkrement definiert. Post-increment macht also die gleiche Arbeit plus etwas extra. Normalerweise erstellt dies eine Kopie und gibt dann die Kopie über eine Kopie zurück (das Pre-Inkrement kann sich selbst als Referenz zurückgeben, aber das Post-Inkrement kann nicht).

Answer 5

Im Ernst, es sei denn, Sie tatsächlich zu rufen Nachinkrement statt Prä-Inkrement der Leistungsunterschied WILL NUR MATTER IN SEHR seltenen Fällen Leistungsprobleme aufgrund haben.

---

aktualisiert

Zum Beispiel, wenn Ihre Software ist eine Klimasimulation und operator++ bewirkt, dass die Simulation einen Schritt vorwärts bewegen (dh ++simulation gibt Ihnen den nächsten Schritt in der Simulation, während simulation++ erstellt eine Kopie des aktuellen Schritts in der Simulation, führt die Simulation fort und übergibt Ihnen dann die Kopie), dann wird die Leistung ein Problem sein.

Realistischer, in einem Kommentar erwähnt der ursprüngliche Fragesteller, dass wir ein eingebettetes Projekt mit (scheinbar) Echtzeitanforderungen diskutieren. In diesem Fall müssen Sie sich Ihre spezifische Implementierung ansehen.Ich bezweifle ernsthaft, dass Sie merkliche Verlangsamungen haben werden, die durch eine std::vector mit Post-Inkrement anstelle von Pre-Inkrement durchlaufen, obwohl ich keine STL-Implementierung in dieser Angelegenheit Benchmarking.

---

Wählen Sie aus Leistungsgründen nicht den anderen. Wählen Sie eines aus Gründen der Klarheit/Wartung aus. Persönlich setze ich das Vorinkrementieren fort, weil es mir im Allgemeinen egal ist, was der Wert vor dem Inkrementieren war.

Wenn Ihr Gehirn explodiert, wenn Sie ++i statt i++ sehen, kann es Zeit sein, in eine andere Arbeitslinie zu gehen.

Answer 6

Ich weiß, das ist wie "Hangar-Flying" in der Luftfahrt. Ich bin sicher, dass es rein akademisch ist, und Sie wissen, wenn es einen Unterschied macht, müssen Sie Ihren Code neu denken.

Beispiel: Ich habe einen Kommentar auf einige Antwort, die ich bis zu einem gewissen Frage zu Performance-Tuning gab, und es ging so:

Person: Ich habe versucht, Ihre Methode zufällig stoppen und an den Call-Stack suchen. Ich habe es mehrmals gemacht, aber es macht keinen Sinn. Die ganze Zeit ist es tief in irgendeinem Iterator-Inkrement-Code. Was ist das gut?

Ich: Das ist großartig! Es bedeutet, dass fast die gesamte Zeit in inkrementelle Iteratoren geht. Schau einfach höher auf den Stapel und sieh, wo er herkommt. Ersetzen Sie das durch einfaches Integer-Inkrement, und Sie erhalten eine massive Beschleunigung.

Natürlich bevorzugen Sie vielleicht die Schönheit der Iterator-Inkrementierung, aber es ist einfach genug, um herauszufinden, ob es Sie viel Leistung kostet.

Answer 7

Ich habe gelesen, dass es keinen Unterschied mit Compilern macht, die einen anständigen Optimierer haben. Da die Gesamtschleifenlogik für beide gleich ist, ist es sinnvoll, ein Vorinkrement als eine gute Programmiergewohnheit zu verwenden. Wenn der Programmierer den "suboptimalen" Compiler findet, ist das beste Ergebnis garantiert.