push_back bei std::list 3X langsamer als bei std::vector

Sone

Kellerautomat schrieb:

Reservier halt mit reserve(). Dann kannste in den vector vermutlich mehr reinstopfen.

Das bringt nichts. reserve() vergrößert max_size() nicht. reserve() kann lediglich viele Reallokationen verhindern.

Kellerautomat

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().

Dobi

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.

hustbaer

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ür push_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.

hustbaer

@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.