ich habe folgenden "Algorithmus": Ich bekomme einen std::vector<IndexHeightPair> elements mit Eingabedaten. Abhängig von bestimmten Attributen dieser IndexHeightPair, wandert jedes Element in mindestens eine "Queue" mit einer bestimmten Nummer. Ein Element kann in eine, zwei oder vier Queues gesteckt werden.

Zum besseren Verständnis hier grob der Algo:

std::map<int, std::vector<IndexHeightPair> > queues;
IndexHeightPair pair;

for(int i=0, numElments = elements.size(); i < numElments; i++) {

   pair = elements[i];

   index = ... // Errechne index für das aktuelle element

   queues[index].push_back( pair ); // Element kommt immer in mind. 1 "Queue"

   if( .. bestimmte Bedingungen ..) {
       queues[index - 1].push_back( pair );
       queues[index - mNumEdgesAlongSide].push_back( pair );
       queues[index - mNumEdgesAlongSide - 1].push_back( pair );
   }
   else if(.. bedingung ..) {	
      queues[index - mNumEdgesAlongSide].push_back( pair );
   }
   else if(.. bedingung ..) {
      queues[patchIndex - 1].push_back( pair );
   }
}

Ich denke hier sieht man ganz gut, was ich meine. Für jedes Element wird ein Index berechnet und abhängig von diesem wird dann das Element in einer, zwei oder vier queues gesteckt. Meine Datenstruktur queues ist eine map<>, deren Key die Queue Number ist und der Value ein std::vector<>.
Wenn die schleife beendet ist, sieht die map z.B. so aus:
queues[3] == {element1, element3, element100}
queues[4] == {element1, element44}
queues[11] == {element23}
Die Queue Nummern sind meistens nicht zusammenhängend.
Mein Problem ist nun: Ich hab den Code gestest und er ist extrem langsam (auch im Release Modus). Zu Testzwecken habe ich mal die push_back() auskommentiert, und dann lief meine Anwendung wieder richtig schnell. Kann das eine bestätigen oder sich erklären, wieso das push_back() hier langsam sein könnte?

Offenbar sind also die push_back() der map relativ langsam. Meine Frage ist nun: Wie kann ich meine Datenstruktur mit etwas anderem als std::map abbilden? Meine Queues müssen NICHT sortiert sein. Gibts da eine schnellere Alternative oder was ganz anderes?

Danke für Hilfe

Ist IndexHeightPair ein Typ der langwierig zu kopieren ist? Falls ja solltest du die vielen Kopien vermeiden und lieber mit Zeigern arbeiten.

Werden in einem Durchlauf viele Elemente in die queues gepackt? Falls ja: std::vector ist nicht so ideal, wenn seine Größe schnell wächst. Falls möglich, sollte man vorher schonmal den Speicher reservieren. Falls dies nicht möglich ist, sollte man eine wachstumsfreudigeren Container wie deque oder list verwenden.

Und eine Anmerkung:
Ich glaube nicht, dass map hier das Problem ist. Es ist wohl eher, dass hier sehr viele Kopien von IndexHeightPair Objekten gemacht werden. Einmal bei jedem push_back und immer wenn der vector in der queue neuen Speicher braucht, muss er alle seine Elemente in den neuen Speicherbereich kopieren. Falls IndexHeightPair mehr als nur eine handvoll Datenelemente hat, kommt da ganz schön was zusammen.

Du kannst ja mal einen Profiler benutzen, dann siehst du, welche Unterfunktion es genau ist, die so lange braucht bzw. so oft aufgerufen wird.

In der Praxis hat bei mir vector gegen list immer die Nase weit vorn. Wäre das Zeug teuer zu kopieren, dann wäre es Unfug, es in vier Listen zu stopfen, sondern man würde Zeiger stopfen. Mit wieder klarstem Sieg für vector.

Queue oder vector? Hängt von der Datenlage ab. Sind die Objekte eher Schnellkopierer kann vector netter sein. Hier schien mir das so. Und vor allem ist zu hoffen, daß vector weniger Speicher frißt. Ich hatte den Eindruck, als gäbe es zehntausende von queues, manche davon blieben ganz leer, viele hätten sehr wenige Elemente. War nur so ein Gefühl. Da dann immer für die queue eine ganze Speicherseite zu allokieren, würde mir weh tun.

Und man braucht keinen profiler. Es reicht clock().

volkard schrieb:

warum kein std::vector<std::vector<IndexHeightPair> > queues ?

Das würde natürlich gehen, aber ich hielt map erstmal für eleganter, da ich ja teilweise große Lücken in den Queue-Indices habe. Es kann durchaus sein, dass ich in Queue[2] 100 Elemente habe und die nächste Queue ist Queue[80]. Alle Queues dazwischen brauche ich quasi nicht (haben 0 Elemente).
Sehe ich das richtig, dass wenn ich diese verschachtelte vector Datenstruktur nehme, ich zuvor die Größen festlegen muss? Also so z.B:

queues.resize(mNumQueues); // Die Maximalzahl an Queues kenne ich
   for(uint i=0; i < queues.size(); i++)
      queues[i].resize(mNumElements); // Mögliche Maximalzahl in einer Queue

?

@SeppJ: Die IndexHeightPair Struktur ist sehr simpel:

struct IndexHeightPair {
   uint  row, col;	
   float height;		
};

Ich ging davon aus, dass so eine kleine Struktur keine Probleme macht. Das

pair = elements[i];

habe ich nur gemacht, weil ich dachte das könnte Performance bringen, wenn ich den vektor nur EINMAL deferenziere und dann nur noch mit pair arbeite. Sonst hätte ich an mehreren Stellen in der Schleife (unter anderem bei allen push_backs) ein elements[i].

Ich könnte mir mittlerweile auch vorstellen, dass garnicht die map das Problem ist, sondern ein mögliches "geresize" der vektoren bei den push_back().
Nur habe ich da 2 Probleme: Ich weiß ja vor Betreten der Schleife nicht, welche Queue-Nummern rauskommen werden - ich kann also nicht im Voraus die entsprechenden Vektoren resizen().
Das 2. Problem: Offenbar ist auch ein manuelles Aufrufen von Resize() langsam. Ich habe nur mal zum Test in meinen schnell ausführenden Code das hier eingefügt:

std::vector< std::vector<IndexHeightPair> > queues(mNumQueues, 	std::vector<IndexHeightPair> ( 500 ));

und sofort war meine Performance wieder im Keller!

So wie ich das im Moment sehe, wäre wohl das das schnellste:
Ich lege EINMAL einen vector<vector<IndexHeightPair>> an und resize ihn.
Vor der Schleife gehe ich dann über den vector und rufe für jeden inneren Vektor clear auf:

for(uint i=0; i < queues.size(); i++)
   queues[i].clear();

Meint ihr das ist gut/elegant?

volkard schrieb:

warum kein std::vector<std::vector<IndexHeightPair> > queues ?

Das würde natürlich gehen, aber ich hielt map erstmal für eleganter, da ich ja teilweise große Lücken in den Queue-Indices habe. Es kann durchaus sein, dass ich in Queue[2] 100 Elemente habe und die nächste Queue ist Queue[80]. Alle Queues dazwischen brauche ich quasi nicht (haben 0 Elemente).

Nicht so schlimm. Ein leerer vector sollte nur 8 Bytes oder so fressen.

mapper schrieb:

Sehe ich das richtig, dass wenn ich diese verschachtelte vector Datenstruktur nehme, ich zuvor die Größen festlegen muss? Also so z.B:

queues.resize(mNumQueues); // Die Maximalzahl an Queues kenne ich
   for(uint i=0; i < queues.size(); i++)
      queues[i].resize(mNumElements); // Mögliche Maximalzahl in einer Queue

?

Das wäre Bockmist.
Machen nur

queues.resize(mNumQueues); // Die Maximalzahl an Queues kenne ich

damit der Indexzugriff queues[index] geht. Dort liegt dann ein korrekter (aber noch leerer) vector. queues[index].push_back( pair ); geht dann auch.

Ich könnte mir mittlerweile auch vorstellen, dass garnicht die map das Problem ist, sondern ein mögliches "geresize" der vektoren bei den push_back().

Nein. Was soll das für einen Vorteil haben, das erste new für jeden vector vor der Hauptschleife auszuführen, statt nur für jeden benötigten vector in der Hauptschleife? für das "if(size==capacity) grow();" im pushback muß eh immer ein (sehr billiges, weil praktisch immer richtiggeratenes) if gezahlt werden.

Nur habe ich da 2 Probleme: Ich weiß ja vor Betreten der Schleife nicht, welche Queue-Nummern rauskommen werden - ich kann also nicht im Voraus die entsprechenden Vektoren resizen().

Gut. Glück gehabt. Sonst hättest Du noch an Unfug gedacht.

Das 2. Problem: Offenbar ist auch ein manuelles Aufrufen von Resize() langsam. Ich habe nur mal zum Test in meinen schnell ausführenden Code das hier eingefügt:

std::vector< std::vector<IndexHeightPair> > queues(mNumQueues, 	std::vector<IndexHeightPair> ( 500 ));

und sofort war meine Performance wieder im Keller!

Jup.

So wie ich das im Moment sehe, wäre wohl das das schnellste:
Ich lege EINMAL einen vector<vector<IndexHeightPair>> an und resize ihn.
Vor der Schleife gehe ich dann über den vector und rufe für jeden inneren Vektor clear auf:

for(uint i=0; i < queues.size(); i++)
   queues[i].clear();

Meint ihr das ist gut/elegant?

[/quote]
Warum clear für jeden vector aufrufen? Die waren doch schon alle leer. Noch leerer kannst Du sie nicht machen.

Ich könnte mir mittlerweile auch vorstellen, dass garnicht die map das Problem ist, sondern ein mögliches "geresize" der vektoren bei den push_back().

Das Gerücht des lahmen vectors wiedermal? Ich muß wohl mal ein Bildchen malen, das zeigt, wie unheimlich wenig Resizen benötigt wird und wie unheimlich wenige Takte das braucht.

Warum clear für jeden vector aufrufen? Die waren doch schon alle leer. Noch leerer kannst Du sie nicht machen.

Der Code von oben (die Schleife) steht in einer Methode (nennen wir sie mal Foo), die pro Sekunde ca. 1000 Mal aufgerufen wird (1000 FPS).
Wie ich bereits geschrieben habe, ist bei meinem Test der std::vector<std::vector<IndexHeightPair> > ein Member der Klasse und ich rufe das resize() auf dem vector nur EINMAL auf. Nach jedem Aufruf der Methode ist der vector natürlich gefüllt und ich muss ihn vor dem nächsten Durchlauf leeren. Drum das clear().

[code="volkard"]Das Gerücht des lahmen vectors wiedermal? Ich muß wohl mal ein Bildchen malen, das zeigt, wie unheimlich wenig Resizen benötigt wird und wie unheimlich wenige Takte das braucht.[/quote]
Naja, was heißt hier Gerücht? Fakt ist: Meine Anwendung hat, wenn ich die Methode Foo (sprich die Schleife) nicht aufrufe ziemlich konstant 1000 fps. Sobald ich Foo aufrufe, brechen die FPS auf 70 (!!) FSP ein.

Mir konnte nach wie vor keiner sagen, WAS denn jetzt eigentlich so extrem langsam ist in meinem Code. Fakt ist:
Wenn ich alle push_back() auskommentiere, dann habe ich wieder meine 1000fps.
Ich habe mal als Test ALLES in Foo auskommentiert und nur das reingeschrieben:

std::vector< std::vector<IndexHeightPair> > queueTest;
queueTest.resize(64);

und alleine diese 2 Zeilen lassen die FPS von 1000 auf ca 100 sinken. Offenbar IST resize() also ein absoluter Performance-Killer, drum wollte ich das ganze resize() EINMAL im Ctor erledigen und dann nie wieder.

Im Moment habe ich jetzt folgenden Code: Ich habe die Datenstruktur als Member der Klasse gemacht:

std::vector< std::vector<IndexHeightPair> > queues;

und reserviere im Ctor EINMAl Speicher:

queues.resize(mNumQueues);

Die Schleife sieht dann exakt so aus wie oben, nur das ich vor jedem Schleifendurchlauf noch alle Vektoren leere:

for(uint i=0; i < queues.size(); i++)
   queues[i].clear();

Der Code ist jetzt schon schneller, aber noch immer recht lahm (von 1000fps runter auf 200).
Ich würde noch immer gerne wissen:
+ Was nun in meinem alten Code so extrem lahm war (und jetzt auch noch immer ist)
+ ob ich das noch weiter verbessern kann bzgl Performance?

struct IndexHeightPair { 
   uint  row, col;    
   float height;        
};

sind also mindestes 12Byte(2x unit = 2x >=4, 1xfloat = 1x4), die jedes mal wieder kopiert werden müssen - evtl solltest du lieber mit Pointern arbeiten!?
imho liegt die grenze zwischen value/pointer(bzw. reference) bei einem DWORD(also 8 Byte auf nem 32bit System) - du kannst ja mal probieren, was rauskommt, wenn du mit pointern darauf arbeitest
Voraussetzung ist natürlich, dass die Objekte irgendwo anders schon existieren und nicht erst auf dem heap konstruiert werden müssen...

bb

std::map<int, std::vector<IndexHeightPair> > queues;

boost::tuple()?

noch ein kleiner Tipp.
Bei

pair = elements[i];

kopierst du auch noch mal die Daten.
Benutze besser eine konstante Referenz darauf:

const IndexHeightPair &pair = elements[i];

Der push_back wird nicht das Problem sein, sondern der map-Operator [], da dieser ja zuerst den leeren Vector auf dem Heap anlegen muß (mittels new).
Teste mal:

queues[index - 1]; // .push_back( pair );

Sollte dann noch genauso 'langsam' sein...

Sofern du noch weiterhin Zugriff auf den Eingangsvector 'elements' hast (und sich dieser nicht ändert), so könntest du auch Indizes bzw. Referenzen auf die Werte benutzen (wie schon von anderen vorgeschlagen).

Und so richtig scheinst du die STL-Klassen noch nicht verstanden zu haben (ich beziehe mich dabei auf deine Wortwahl, z.B. "... push_back() der map ..."):
die push_back-Funktion wird für den vector aufgerufen!!!