push_back bei std::list 3X langsamer als bei std::vector
-
Wie ich vermutet habe. Die Liste wird schneller, wenn die Objektgröße steigt.
Ab einer gewissen Größe wirft vector zudem nen bad alloc.
-
Wenn die Objektgröße auf was steigt? 100MB?
-
Ganz so schlimm ist es nicht
-
Reservier halt mit reserve(). Dann kannste in den vector vermutlich mehr reinstopfen.
-
Kellerautomat schrieb:
Reservier halt mit reserve(). Dann kannste in den vector vermutlich mehr reinstopfen.
Das bringt nichts.
reserve()vergrößertmax_size()nicht.reserve()kann lediglich viele Reallokationen verhindern.
-
Das bringt sehr wohl was, wenn der benoetigte Speicher + der momentane Speicher = temporaer waehrend einer Reallokation gebrauchte Speicher den verfuegbaren Speicher ueberschreiten, aber der benoetigte Speicher geringer ist als der verfuegbare.
-
Wie die meisten hier vermuten lag das Problem nicht an std::vector, sondern an einer andern Stelle begraben.
Von daher bleibe ich beim gewohnten std::vector
Reserve benutze ich btw. soweit es geht immer
Es sei denn ich stell hier nen kleines snippet rein.
Ich wusste allerdings nicht, dass der std::vector in zweierpotenzen von allein reserved
-
BTW: Eigentlich benutz ich resize() statt reserve().
-
Du weißt aber schon, dass resize was ganz anderes macht als reseve?
http://en.cppreference.com/w/cpp/container/vector/resize
http://en.cppreference.com/w/cpp/container/vector/reserve
-
Mittlerweile schon
Vielleicht werde ich zukünftig auch mal reserv-ieren.
-
dgrat_87 schrieb:
Ich wusste allerdings nicht, dass der std::vector in zweierpotenzen von allein reserved
MSVC nimmt soweit ich weiss 3/2.
Es muss aber immer abhängig von der vorherigen Grösse sein - mit fixen Schritten könnte man die Forderungen des Standards nicht hinbekommen (amortisiert konstante Zeit fürpush_back).
-
hustbaer schrieb:
Es muss aber immer abhängig von der vorherigen Grösse sein - mit fixen Schritten könnte man die Forderungen des Standards nicht hinbekommen
Könnte auch abhängig von den Ticks seit Systemstart sein. Oder abhängig von den bisher erledigten Reallokationen des Vektors (ist unabhängig von der Grösse wenn es durch swap() nicht verändert wird).
Jedenfalls muss immer mehr allokiert werden je grösser der Vektor wird.
-
@americanjurist
Ja std::vector könnte sich auch gleich den gesamten Speicher der Maschine grabschen. Unsinnige Alternativen sind leicht zu finden. Wenn du was an meinem immer zu kritisieren hast, dann bitte mit einen realistischen Gegenvorschlag.Wir können uns aber auch gerne darauf einigen dass es keine sinnvolle Alternative gibt als die Wachstumsschritte von der alten Grösse abhängig zu machen.
-
americanjurist schrieb:
Könnte auch abhängig von den Ticks seit Systemstart sein. Oder abhängig von den bisher erledigten Reallokationen des Vektors (ist unabhängig von der Grösse wenn es durch swap() nicht verändert wird).
Beides erfüllt die Vorgaben des Standards über das Laufzeitverhalten der Operationen auf std::vector nicht, also könnte das gerade nicht sein.
