ich hab beispielsweise folgende Struktur:

struct list{
  char point[128];
  long L1;
  long L2;
  int i;
  double wert1;
  double wert2;
  double wert3;
  char c1,c2,c3,c4;
  list *next;
};

Jede mit new angelegte Struktur ist eine Zeile in einer Tabelle
und *next ist immer die nächste Struktur in der Tabelle.

Beim Schließen der Tabelle wird folgender Code ausgeführt um den Speicher der Strukturen wieder frei zu geben:

list *f=first,*f2;
while(f){
  f2=f->next;
  delete(f);
  f=f2;
}

Das Funktioniert alles wunderbar ... nur wenn ich dann eine Tabelle mit 30000 Einträgen habe und diese dann schließe dauert das gute 5-6 Sekunden.

Meine Frage ist nun gibt es einen Weg das zu beschleunigen??

Vielen Dank im Voraus

Jan

#include <list>

struct DataItem
{
  char point[128];
  long L1;
  long L2;
  int i;
  double wert1;
  double wert2;
  double wert3;
  char c1,c2,c3,c4;
};

std::list<DataItem> myList;

struct dings {
  char point[128];
  long L1;
  long L2;
  int i;
  double wert1;
  double wert2;
  double wert3;
  char c1,c2,c3,c4;
};

int main()
{
  :::
  std::vector<dings> bums;
  :::
}

oder std::list, oder std::list mit einem boost::pool_allocator (?)

Am besten in der Reihenfolge, falls möglich.

[...] oder std::list mit einem boost::pool_allocator (?).

Da würde ich eher 'ne intrusive Liste nehmen.

Ich werde mir dann einmal anschauen was ein allocator ist ....

Wieso das und nicht einfach std::vector benutzen? Der ist nämlich in vielen Gebieten einer linked List hoffnungslos überlegen.

Wenn Du den delete Operator erstmal leer läßt, kannst Du auch schön sehen, ob dort die Zeit bleibt, oder ob es immer noch langsam ist. Das produziert natürlich massig Memoryleaks, aber zum Testen ist das ja egal.

Wenn das erfolgreich war müsstest Du den Speicher für Deine Objekte selber verwalten. Typischerweise fordert man gleich Speicher für viele Objekte an und verwaltet diese dann selber. Aber da kann man natürlich auch auf fertige Lösungen zurückgreifen...

@dibada: wo könnte ich denn solche fertigen Lösungen finden ??

Du darfst aber grundsätzlich auch nochmal drüber nachdenken oder nachfragen, wenn Dir hier drei erfahrene Leute sagen, dass das ein oder andere für Dich besser geeignet ist

EDIT:

janmerkschien schrieb:

@dibada: wo könnte ich denn solche fertigen Lösungen finden ??

Das meinst Du jetzt nicht ernst?

wenn ich vector benutze würde das an der ganzen sache nix ändern ....
es würde trotzdem für jede struktur im vector ein delete aufgerufen und so würde der zeitaufwand der selbe bleiben ^^
(wenn ich das richtig verstanden habe)

Nein, hast Du nicht.

wenn ich vector benutze würde das an der ganzen sache nix ändern ....
es würde trotzdem für jede struktur im vector ein delete aufgerufen und so würde der zeitaufwand der selbe bleiben ^^
(wenn ich das richtig verstanden habe)

Eben nicht!
std::vector ist ein toller Wrapper um

new DataItem[xyz];

, der dem manuellen Speicher verwalten auf jeden Fall vorzuziehen ist.

std::vector besorgt nur einmal Speicher für ALLE Elemente, ist halt ein Array. Wenn der Vektor voll ist, alloziert er mehr Speicher (ca doppelt so viel) und kopiert in den neuen Bereich.

Wenn du die Anzahl der Objekte abschätzen kannst, hast du mit einem std::vector genau 1 new und 1 delete. Wenn du mit einem leeren vector startest und immer anhängst, hast du um den Dreh log(n) + x Allocations/Deletes (Der Vektor muss wachsen).

@Ethon:
der vector würde dann immer wieder eine Struktur dazu bekommen also insgesamt 72660 mal ...
und dann hätte ich ja wieder 72660 Allocations/Deletes oder?

der vector würde dann immer wieder eine Struktur dazu bekommen also insgesamt 72660 mal ...
und dann hätte ich ja wieder 72660 Allocations/Deletes oder?

Ne, immer noch nicht.

Ethon schrieb:

Eben nicht!
std::vector ist ein toller Wrapper um

new DataItem[xyz];

Toll ja, aber nicht einmal vector verwendet intern new[] .

Wenn du die Anzahl der Objekte abschätzen kannst, hast du mit einem std::vector genau 1 new und 1 delete. Wenn du mit einem leeren vector startest und immer anhängst, hast du um den Dreh log(n) + x Allocations/Deletes (Der Vektor muss wachsen).

den satz verstehe ich so das pro liste die angehängt wird eine Allocation und ein Delete hinzu kommt.

Toll ja, aber nicht einmal vector verwendet intern new[].

Der std::vector verwendet per default std::allocator und der new[].
Also doch.

den satz verstehe ich so das pro liste die angehängt wird eine Allocation und ein Delete hinzu kommt.

Okay, dann langsam. Stell dir vor der Vektor hat am Anfang Platz für 20 Elemente. Dann muss die nächsten 20x Anfügen kein new aufgerufen werden. Ab 20 muss neuer Speicher her. Also besorgt der Vektor beispielsweise Speicher für 60 Elemente und entfernt den alten Speicher per delete. Bis die 60 voll sind muss wieder kein new aufgerufen werden, dann wieder 1x new + 1x delete. Wenn der Vektor seinen Wertebereich verlässt und der Destruktor aufgerufen wird, ist noch 1 delete fällig. Das wars.

Toll ja, aber nicht einmal vector verwendet intern new[].

Der std::vector verwendet per default std::allocator und der new[].
Also doch.

Wo steht das? Ist dir klar, dass das nicht funktionieren kann?
allocator<T>::allocate liefern einem ein Stück Speicher für n Elemente, angefordert mit ::operator new . Konstruktoren werden dann mit placement new bzw. allocator<T>::construct aufgerufen.

Ethon schrieb:

Toll ja, aber nicht einmal vector verwendet intern new[].

Der std::vector verwendet per default std::allocator und der new[].
Also doch.

Wo steht das? Ist dir klar, dass das nicht funktionieren kann?
allocator<T>::allocate liefern einem ein Stück Speicher für n Elemente, angefordert mit ::operator new . Konstruktoren werden dann mit placement new bzw. allocator<T>::construct aufgerufen.

Da new[] das auch so macht, sollte man es vielleicht so forumlieren: Der Standardallocator macht das gleiche wie new[], auch wenn es technisch kein Wrapper um new[] ist.

#include <ctime>
#include <list>
#include <iostream>

int main()
{
	auto t = std::clock();
	{
		std::list<int> l;
		for (auto i = 5000000; i--; )
			l.push_back(i);
		auto elapsed = (std::clock() - t) / static_cast<double>(CLOCKS_PER_SEC);
		std::cout << "Elapsed alloc: " << elapsed << '\n';
	}
	auto elapsed = (std::clock() - t) / static_cast<double>(CLOCKS_PER_SEC);
	std::cout << "Elapsed dealloc: " << elapsed << '\n';
}

Insofern könnte der TE mal schreiben was er da bei sich veranstaltet.

Insofern könnte der TE mal schreiben was er da bei sich veranstaltet.

Debugbuild? Wenn man alle Aktionen auf ihre Richtigkeit prüft (ok, das macht auch eine optimierte (De-)Allokation noch) und noch tolle Heapguards einbaut und diese auf Überschreiben prüft, dann dauert das ganz schön lange.

Aus der IDE brauch es bei mir tatsächlich, ungeachtet vom Release oder Debug ca. 2-3 Sekunden mit seiner Datenstruktur. Von der Konsole aus braucht das Release 0,025 Sekunden (und das Debug doppelt so lange).

Sprich: Für eine Zeitmessung sollte man scheinbar neuerdings auch die IDE verlassen.

Sprich: Für eine Zeitmessung sollte man scheinbar neuerdings auch die IDE verlassen.

Naja, das ist schon länger so.
Bzw. es geht glaube ich primär darum dass kein Debugger auf dem Prozess draufhängt.