STL und Performance
-
würd mich mal interessieren, inwiefern beispielsweise die string-Klasse bei exzessiver Nutzung (schreib-lese-vergleichs-operationen) auf die Performance auswirkt (gegenüber selbst implementierten Suchen)
Mir gehts darum, dass ich gern mit assoziativen Arrays (map<string, float>, oder ähnlich)arbeiten würde. Dass dies langsam ist, ist mir klar, aber ob sich sowas beispielsweise in der Spieleprogrammierung beispielsweise als DB in einem Textadventure, etc. trotzdem noch lohnt würd mich mal interessieren..
Bei Datenbanken ist das ja eigentlich nur selten nen Problem, wenn der Benutzer mal ne halbe Sekunde wartet..
Soo, damit's sich auch noch für die heldenliste lohnt: mir fallen immer solche Dinge ein, wenn meine Tochter mich nachts nicht schlafen lässt und es lässt mich dann auch nicht mehr los..
-
DocJunioR schrieb:
würd mich mal interessieren, inwiefern beispielsweise die string-Klasse bei exzessiver Nutzung (schreib-lese-vergleichs-operationen) auf die Performance auswirkt (gegenüber selbst implementierten Suchen)
du verleichst äpfel mit birnen.
std::string kann nicht besser oder schlechter sein irgendwelche suchen, denn sie haben disjunkte aufgabenbereiche.Mir gehts darum, dass ich gern mit assoziativen Arrays (map<string, float>, oder ähnlich)arbeiten würde.
ok. ich frage mich zwar ein wenig, warum man das macht. aber ich nehme mal map<string,float> als arbeitshypothese an.
Dass dies langsam ist, ist mir klar, aber ob sich sowas beispielsweise in der Spieleprogrammierung beispielsweise als DB in einem Textadventure, etc. trotzdem noch lohnt würd mich mal interessieren..
du willst total viel nach zeichenketten siuchen und auch total viele änderungen an der db machen? das ist kein problem von string. gar keins. strings sind, wenn einmal angelegt, einfach schnelle dinger. allein der baum in der map könnte speedup vertragen.
aber das hängt ganz und gar von den daten ab. wenn du einfach gar keine aussage über die daten machen kannst, wirste map<string> nicht schlagen. wird nur am anfang eingefügt und danach tierisch oft gesucht? dann bieten sich natürlich auch hashtables an mit doppeltem hashing und ohne getrennten überlaufbereich. aber die bieten sich nur an, wenn du kurze strings hast. bei langen strings vielleicht ternery search trees. oder enfach eine sorierte liste und binäre suche. sind die suchanfragen eher gleichverteilt? bei sehr ungleichverteilten suchen (wenn der user nur nach strings sucht, die im raum snd, in der er grade rummrennt oder sowas) und wenigen elementen denke man an move-to-front-lists. bei mehr elemeten mit meiner technik "swap(i,i-i/16+1)" oder gat spreizbäumen.
wenn du von der konkreten aufgabenstellung abstrahierst, muß ich leider von der genauen lösung abstrahieren, und zwar mindestens so weit, weil du einfach keine informationen lieferst, die detail-entscheidungen ermöglichen.
allgemein läßt sich nur sagen, je mehr assembler du verwendest, desto schneller wird das spiel.
-
Dann könnte man vielleicht noch anmerken, dass es für ein Textadventure wohl reichen wird.
-
Naja, ob Textadventure oder massive multiplayer was-weiß-ich ist ja wurscht.
Ich bin die C64-Manie, Rechenzeit und Speicher zu sparen nie losgeworden..
Gut, wenn ihr der meinung seid, dass es hier keine Probleme gibt, ist das fein.Mit der Map selber hab ich uach noch nicht gearbeitet, aber so großartig anders als nen vector isses ja nicht..
-
DocJunioR schrieb:
Naja, ob Textadventure oder massive multiplayer was-weiß-ich ist ja wurscht.
Ne, domain specific optimization ist immer noch die beste optimierung die es gibt.
Ich bin die C64-Manie, Rechenzeit und Speicher zu sparen nie losgeworden..
dann wuerde ich mal schnleunigst die strings zu ints machen