Ich habe die Geschwindigkeit verschiedener Wege auf einem std :: vector getestet. Im folgenden Code betrachte ich 5 Möglichkeiten, um die Summe aller Elemente eines Vektors von N = 10000000 Elementen zu berechnen:
Der Code wird mit g ++ für Windows kompiliert, die zum Kompilieren verwendete Befehlszeile lautet:
%Vor%Ich habe den Code viermal ausgeführt, wobei ich die Zeit jeder Methode gemessen habe. Ich erhalte die folgenden Ergebnisse (Zeit in Mikrosekunden, Max und Min sind angegeben):
Was diese Experimente zu zeigen scheinen, ist:
Das Schleifen mit Iteratoren gegen ganzzahlige Indizes macht zumindest bei vollständiger Optimierung keinen großen Unterschied.
Das Abwickeln der Schleife zahlt sich aus
Überraschenderweise ergibt das stl :: accumum die schlechtere Leistung.
Während die Schlussfolgerungen 1 und 2 etwas erwartet wurden, ist die Zahl 3 ziemlich überraschend. Sagen nicht alle Bücher, die STL-Algorithmen zu verwenden, anstatt selbst Schleifen zu schreiben?
Mache ich einen Fehler in der Art und Weise, wie ich die Zeit gemessen habe, oder in der Art und Weise, wie ich die Ergebnisse interpretiere? Habt ihr ein anderes Szenario, falls ihr den unten angegebenen Code ausprobiert?
%Vor%Der Grund für die Verwendung der Standardbibliotheksalgorithmen ist nicht , um eine bessere Effizienz zu erreichen, sondern um Ihnen zu ermöglichen, auf einer höheren Abstraktionsebene zu denken.
In einigen Fällen ist der Algorithmus zwar schneller als Ihr eigener handgenerierter Code, dafür sind sie aber nicht da. Einer der großen Vorteile von C ++ ist, dass Sie die integrierten Bibliotheken umgehen können, wenn Sie einen bestimmten Bedarf haben. Wenn Ihr Benchmarking gezeigt hat, dass die Standardbibliothek eine kritische Verlangsamung verursacht, können Sie klassische Alternativen wie Loop Unrolling erkunden. Für die meisten Zwecke wird das nie nötig sein.
Damit wird ein gut geschriebener Standard-Bibliotheksalgorithmus nie schrecklich langsamer sein als Ihre eigene einfache Implementierung, es sei denn, Sie nutzen die Kenntnis der Besonderheiten Ihrer Daten.
Zusätzlich zu Mar würde ich das denken STL ist in den meisten Fällen nicht schneller als Ihre eigene Implementierung, da es sich um eine allgemeine Lösung für eine Reihe verwandter Fragen handelt, aber nicht für eine bestimmte. Daher ist es wahrscheinlich, dass STL mehr Faktoren berücksichtigt, als Sie wirklich benötigen, also weniger effizient. Aber es gibt eine Ausnahme: stl :: sort verwendet eine subtile Optimierung (vielleicht einen Mix aus verschiedenen Sortieralgorithmen), so dass es schneller als übliche Implementierungen funktioniert.