Ich bin auf ein seltsames Verhalten von std :: set gestoßen.
Hier ist der Code:
%Vor%Ich laufe auf Windows XP.
Hier ist der interessante Teil: Diese erste gedruckte Zeit beträgt etwa 3500 ms, während alle folgenden über 9000 ms sind! Warum passiert das?
Oh, und das passiert nur in der Release-Version (-O2-Optimierung).
Unter Linux passiert es nicht (nachdem der Code dort kompiliert wurde).
Noch eine Sache: Wenn ich es beim Profiling mit Intel VTune starte, dauert es immer etwa 3000 ms, also sollte es so sein.
UPDATE: Hier ist ein neuer Code:
%Vor%Das ist das gleiche Problem. Was passiert, ist, dass ich viele viele kleine Objekte zuteile und sie dann in zufälliger Reihenfolge lösche - ähnlich wie es in std :: set aussieht. Das ist also Windows-Speicherverwaltungsproblem. Es kann nicht wirklich viele kleine Zuweisungen und Löschungen behandeln.
Ich kann nicht genau erklären, warum das passiert, aber ich könnte eine Lösung vorschlagen. Ich konnte dies auf meinem PC reproduzieren, wenn ich den Release-Build unter dem Debugger (mit F5 ) ausführe. Wenn ich den Build von der Befehlszeile oder mit Ctrl-F5 ausführe, bekomme ich dieses Verhalten nicht.
Dies hat etwas mit dem Debug-Heap zu tun, das standardmäßig beim Start unter dem Debugger aktiviert ist. Es wird sehr detailliert hier beschrieben. Um dies zu verhindern, entweder
Ctrl-F5 (Debug - & gt; Start ohne Debugging). _NO_DEBUG_HEAP=1 hinzu. Wenn ich raten müsste, würde ich sagen, dass es etwas mit der Implementierung der Speicherzuordnungsverfolgung in der Windows / VS-Laufzeit zu tun hat. Wahrscheinlich werden einige interne Listen gefüllt und neu zugewiesen oder etwas anderes entlang dieser Linien.
Ich denke, dass std::set als ein binärer Suchbaum implementiert ist. Da Sie jedes Mal, wenn Sie im Wesentlichen ein kontradiktorisches (Worst-Case-) Szenario für diese Art von Datenstruktur erstellen, jedes Mal um 1 erhöhen (das Neubalancieren des Baums ist bei fast jedem Insert erforderlich).
Außerdem sind es 50 Millionen Inserts, also wird etwas Zeit erwartet, obwohl ich nicht denken würde, dass es 5 ms sind.
Außerdem würde ich nach dem Drucken Ihrer Zeit Ihr "clear" tun, da ich nicht den Grund sehe, warum Sie sowohl das Einfügen als auch das Entfernen von Objekten benchmarken würden.