Maximale Größe von std::vector
-
@Bulli,
Es ging doch nur darum aufzuzeigen, dass ein Namenskonflikt passieren kann. Ich wollte kein vollwertiges riesiges Konstrukt bauen, wo dann per Zufall ein Namenskonflikt entsteht. Es ist doch nur ein BEISPIEL.Zudem verteufle ich es nicht. Ich rate nur zur Vorsicht. Herje.
@"nö du",
Da die Aussage sowieso falsch ist, ist es egal.Grüssli
-
Wow. Das war aber ganz schön Off Topic.
Auf jeden Fall Danke an alle die was beigetragen haben.
Jetzt läuft das Programm. Ich war kurz davor std::deque zu verwenden,
da hab ich mir gedacht versuchs doch mal so:
Da ich ja am Anfang nicht weis wie groß der Vector wird habe ich ihn
immer für jeden Eintrag mir resize erweitert. Jetzt hab ich erst die
Zeilen in der Datei gezählt, die vectoren einmal angelegt und siehe da: Es geht!
Kostet mich aber 30 sec. mehr Laufzeit. Aber bei 2-5 Stunden läßt sich das verschmerzen
-
Ja, das ist eine sehr gute Lösung! Denn so wird der Speicher nicht unnötig fragmentiert, was ja vorher wohl tatsächlich mächtig freien Speicher verschwendete.
-
Da ich ja am Anfang nicht weis wie groß der Vector wird habe ich ihn
immer für jeden Eintrag mir resize erweitert.Aber dir ist klar, dass das unnötig war?!
Jetzt hab ich erst die Zeilen in der Datei gezählt, die vectoren einmal angelegt und siehe da: Es geht! Kostet mich aber 30 sec. mehr Laufzeit. Aber bei 2-5 Stunden läßt sich das verschmerzen
Das halt ich für nen Gerücht, dass es jz länger braucht, obwohl es nicht mehr aller x Einträge umkopieren muss...
btw: Im Release-Mode compiliert?bb
-
es dauert definitiev länger.
Ich mess die Zeit mit:
time(&start);
...vectoren anlegen, datei einlesen...
time(&stop);
cout << stop-start << endl;
(was ich der einfachheit halber unterschlagen hab: in der datei
stehen die zeilen nicht einfach so sondern in sektionen unterteilt.
am anfang jeder sektion steht wie viele zeilen jetzt kommen.
Typischerweise einige tausend... also wird der wevtor nicht bei
jeder zeile vergrößert sondern immer in tausenderschritten)macht ne differenzevon 30 sec.
ansonsten verwende ich den intel C++ Compiler 11 mit den Parametern:
icpc -openmp -parallel -fast main.cppBin aber noch nicht so der Compilerexperte. Wenn jemand optionen kennt die die
Performance verbessern könnten... Her damit!
-
mowo(fs) schrieb:
Wenn jemand optionen kennt die die
Performance verbessern könnten... Her damit!Du könntest doch mal die einzelnen Containertypen ausprobieren.
Wenn es dir wirklich wichtig ist, kannst du auch mit einem Profiler untersuchen, wo sich die Performance-Flaschenhälse in deinem Programm befinden. Auf diese Weise kann sowieso besser optimiert werden als auf gut Glück.
-
profiler.... keine Ahnung was das ist.
Hast du Links/Howtos für mich?
-
tu mal brav push_back benutzen, um den vector zu füllen. und tu nutze nicht resize benutzen! das macht der push_back automatisch und viel besser als du.
und nur wenn das dann nicht klappt, weil du zu wenig speicher hast, dann steig um und benutze queue.
-
mowo(fs) schrieb:
profiler.... keine Ahnung was das ist.
Hast du Links/Howtos für mich?
-
pumuckl du bist mein held!
google. geniale seite! wie bin ich nur so lange ohne die ausgekommen?Ne, mal im ernst: hat wer ne empfehlung für mich?
Linux Profiler für Intell C++ 11 & OpenMP?
Dann muß ich nicht erst 3 Seiten Google durchlesen.
-
Wie wäre es mit Valgrind?
