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

Ich habe ein Programm, dass ich eigentlich mit Hilfe einer linked list optimieren wollte, weil dort ein std::vector sehr oft resized wird.
Allerdings ist die Implementation meiner linked list sehr viel langsamer ):
Da der Inhalt in meinem Programm um einiges größer als ein int sein wird, ahne ich bereits Schlimmeres.
Woran liegt dieses unerwartete Verhalten

namespace ANN {

template<class T>
class vector : public std::list<T> {
public:
	vector()  : std::list<T>() {};
	vector(int n, const T& value = T() ) : std::list<T>(n, value) {};

	T &at(const unsigned int &iPos) {
		assert(iPos < this->size() );
		unsigned int i = iPos;
		for(typename std::list<T>::iterator it = this->begin(); it != this->end(); it++) {
			if(i == 0) {
				return *it;
			}
			i--;
		}
	}

	const T at(const unsigned int &iPos) const {
		assert(iPos < this->size() );
		unsigned int i = iPos;
		for(typename std::list<T>::const_iterator it = this->begin(); it != this->end(); it++) {
			if(i == 0) {
				return *it;
			}
			i--;
		}
		return T();	// error return
	}

	T& operator[](const unsigned int& iPos) {
		return this->at(iPos);
	}

	const T& operator[](const unsigned int& iPos) const {
		return this->at(iPos);
	}
};

#include <iostream>
#include <ANVector.h>
#include <vector>

#include <sys/times.h>

using namespace std;

int main(void) {
	unsigned int max = 100000000;

	long T1, T2;
	struct tms start_time, stop_time;

	T1 = times(&start_time);
	ANN::vector<int> vec;
	for(int i = 0; i < max; i++) {
		vec.push_front(i);
	}
	T2 = times(&stop_time);
	printf ("Execute Time for Loop: %d\n", T2-T1);

	T1 = times(&start_time);
	std::vector<int> vec2;
	for(int i = 0; i < max; i++) {
		vec2.push_back(i);
	}
	T2 = times(&stop_time);
	printf ("Execute Time for Loop: %d\n", T2-T1);

	/*
	for(int i = 0; i < max; i++) {
		std::cout<<vec.at(i)<<std::endl;
	}
	*/
	return 0;
}

Execute Time for Loop: 381
Execute Time for Loop: 39

cooky451

Der vector holt sich auf Verdacht nur in gewissen Abständen neuen Speicher, so oft wie du denkst muss da nichts neu angefordert werden. Eine liste ist nur dann sinnvoll, wenn du Elemente in der Mitte einfügen/löschen willst, und das der größte Performance-Faktor ist. Falls Elemente schnell vorne eingefügt werden müssen, bietet sich eine deque an.

PS: vector von list erben ist mal eine ganz schlechte Idee, was hast du dir denn dabei gedacht?

Sone

Tatsächlich allokiert vector nicht einfach ein Array das nur alle Elemente halten kann, sondern es allokiert jedes mal (jedes mal wahrscheinlich nicht, aber oft) ein Array das noch zusätzliche, noch nicht vorhandene Elemente aufnehmen kann damit nicht immer bei jedem einfügen Speicher reallokiert werden muss.

Der Standard sagt zu den modifizierenden Memberfunktionen:

Causes reallocation if the new size is greater than the old capacity.

Die Kapazität, die durch die Memberfunktion capacity() zurückgegeben wird, bestimmt, wie viele Elemente der vector noch aufnehmen kann bevor eine Reallokation stattfinden muss.
Standard:

size_type capacity() const noexcept;
1 Returns: The total number of elements that the vector can hold without requiring reallocation.

Was auch in diesem Zusammenhang sehr wichtig ist, ist die Memberfunktion reserve() , die schon im Voraus eine Reallokation erzwingen kann:

void reserve(size_type n);
2 Effects: A directive that informs a vector of a planned change in size, so that it can manage the storage
allocation accordingly. After reserve(), capacity() is greater or equal to the argument of reserve if
reallocation happens; and equal to the previous value of capacity() otherwise. Reallocation happens
at this point if and only if the current capacity is less than the argument of reserve(). [....]

Das ist sehr nützlich, falls man weiß das gleich der Vektor sehr groß werden wird, und in bspw. einem Schleifendurchlauf die ganze Zeit neue Elemente, vielleicht sogar einzeln, bekommt.
Dann ist es entspannt, wenn man im Voraus die Kapazität entsprechend groß macht und dadurch eine Reallokation möglicherweise ganz umgeht (was z. T. viel Zeit spart).

Es macht mich bei theoretisch 10^7 möglichen re-alloks alelrdings schon stutzig, dass vector 10x schneller ist, als list.

Ich werde das mal mit größeren Daten testen. Es kann nicht bei jeder typ-größe dermaßen vorreserviert werden.

Dein ganzes Vorgehen ist ziemlich sinnlos. Du nimmst eine std::list um daraus ein vector zu machen. Warum nimmst du nicht gleich den std::vector?

Und dann erbst du von std::list und überschreibst irgendwelche Methoden... Damit zerstörst du evtl. die interne Struktur der std::list und lässt sie erst so ineffizient werden.

Mein Vorschlag: Nimm was aus der STL und programmier erst mal weiter. Sollte es später tatsächlich Probleme geben, kannst du das ganze noch immer austauschen.

Ethon

dgrat_87 schrieb:

Es macht mich bei theoretisch 10^7 möglichen re-alloks alelrdings schon stutzig, dass vector 10x schneller ist, als list.

Wenn du den gcc/clang verwendest, die libstdc++ Implementierung allokiert immer doppelt so viel. Also nichtmal annähernd so viele Allokationen.

Dabei ist Faktor 2 eine schlechte Idee, wie hier erklärt wird: https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

Ethon

dfgdfg schrieb:

Und dann erbst du von std::list und überschreibst irgendwelche Methoden... Damit zerstörst du evtl. die interne Struktur der std::list und lässt sie erst so ineffizient werden.

Er überschreibt nix ... at() und operator[] wurden absichtlich bei std::list nicht implementiert, weil eine Liste eben nur extrem ineffizient random-access anbieten kann.

std::list<int> list = ...;
for(int i = 0; i < n; ++i)
    do_something(list[i]);

hätte eine Komplexität von n!, totale Katastrophe also.

Edit: Nix Fakultät, gerade etwas daneben, aber immer noch katastrophale Laufzeit.

Dobi

dgrat_87 schrieb:

Es kann nicht bei jeder typ-größe dermaßen vorreserviert werden.

Warum kann nicht?
Ob

#include <vector>
#include <iostream>
int main()
{
    std::vector<int> v;
    auto c(v.capacity());
    // Wir push_backend tausend mal was in einen Vector.
    for (int i(0); i < 1000; ++i)
    {
        v.push_back(i);
        // Wenn sie die Kapazitaet geaendert hat,
        // also neu allokiert und umkopiert wurde ....
        if (v.capacity()!=c)
        {
            c = v.capacity();
            // ... geben wir das aus.
            std::cout << c << std::endl;
        }
    }
}

oder

#include <vector>
#include <iostream>
#include <array>
int main()
{
    std::vector<std::array<int,3000>> v;
    auto c(v.capacity());
    // Wir push_backend tausend mal was in einen Vector.
    for (int i(0); i < 1000; ++i)
    {
        v.push_back(std::array<int,3000>());
        // Wenn sie die Kapazitaet geaendert hat,
        // also neu allokiert und umkopiert wurde ....
        if (v.capacity()!=c)
        {
            c = v.capacity();
            // ... geben wir das aus.
            std::cout << c << std::endl;
        }
    }
}

die Ausgabe des executables, das mein Compiler daraus macht, ist in beiden Fällen diese:

Wie ich vermutet habe. Die Liste wird schneller, wenn die Objektgröße steigt.
Ab einer gewissen Größe wirft vector zudem nen bad alloc.

cooky451

Wenn die Objektgröße auf was steigt? 100MB?

Ganz so schlimm ist es nicht

Kellerautomat

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

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