Einlesen von Daten beschleuningen
-
sind das binär oder textdaten? in letzterem falle wird die laufzeit wahrscheinlich primär von der umwandlung dieses textes bestimmt und es gibt im grunde nichts, was man tun könnte, um das signifikant zu beschleunigen. sind es binär-daten sieht die sache anders aus (allerdings kann ich dann kaum glauben, das obige lösung bei gerade 100k daten tatsächlich zu langsam ist - es sei denn, du machst das 100mal innerhalb kurzer zeit
falls du mit textdaten zu tun hast, könnte es sinnvoll sein, das ergebnis in eine binäre cachedatei zu speichern, so das der nächste durchlauf schneller geht, es sei denn, das original wurde verändert. die frage nach gepuffert/ungepuffert dürfte hier relativ uninteressant sein - das betriebssystem puffert ja auch, und bei rein sequentiellem zugriff genügt das oft.
-
handelt sich um textdateien..
und die werden nur einmal beim programmstart geladen. hätte das aber trotzdem gerne schneller..
-
dann verwende die c-io-funktionen
-
und warum soll das so viel schneller sein? kann mir das wer erklären? will ja shcon wissen was ich warum tue...
nen link mit ner info reicht mir auch
-
icdh glaub nich dass die schneller sind... lass doch mal ein profiler drüber laufen, was länger dauert: umwandeln oder aus datei lesen
-
Geh einfach mal mit nem Debugger im Single Step durch und du siehst den Unterschied.
-
Außerdem wäre ein ungepuffertes Lesen trotzdem schneller (entgegen von dem was tntnet schreibt, da Puffern immer Kopieren bedeutet).
kopieren ist aber 1000000 mal schneller, als die festplatte für jedes byte zu bemühen.
-
Th schrieb:
Also optimal ist das noch lange nicht:
Wenn "vertices" ein std::vector ist, dann solltest du vorher "reserve" aufrufen (da du die ungefähre Größe ja zu kennen scheinst).
Außerdem wäre ein ungepuffertes Lesen trotzdem schneller (entgegen von dem was tntnet schreibt, da Puffern immer Kopieren bedeutet).Ich weiß nicht, ob beim fstream auch setbuf(NULL, 0) funktioniert, jedenfalls bei einem FILE geht setbuf(fp, NULL), um in den ungepufferten Modus zu schalten.
"vertices->at( i ) = f1;" würde gar nicht funktionieren, wenn der Vektor nicht vorher auf eine ausreichende Grösse gebracht wurde. Reserve ist da höchstens kontraproduktiv.
Ungepuffertes Lesen ist der Performancekiller! Eines der teuersten Dinge, die man in einem Programm macht, sind Systemaufrufe. Wenn ich ungepuffert lese, also jedes Byte einzeln, dann bedeutet das ein Systemaufruf pro Byte. Deswegen richtet man einen geeignet grossen Lesepuffer ein, den man mit einem Systemaufruf füllen kann.
Tntnet
-
Du könntest auch ne std::list<> benutzen, falls du nacher nicht irgendwie zufällig auf die Daten zugreifen möchtest.
Ne list arbeitet viel schneller als ein vector. Wenn du sie natürlich nur von vorne nach hinten durchläufst und nicht zufällig mal mittendrin einen Wert abfragen willst.
Test it out
-
Freak_Coder schrieb:
Du könntest auch ne std::list<> benutzen, falls du nacher nicht irgendwie zufällig auf die Daten zugreifen möchtest.
Ne list arbeitet viel schneller als ein vector. Wenn du sie natürlich nur von vorne nach hinten durchläufst und nicht zufällig mal mittendrin einen Wert abfragen willst.
Test it out
Wie kommst Du darauf, daß eine list schneller (auch noch viel schneller) als ein vector arbeitet? Das ist mitnichten der Fall. In eine Liste kann ich schneller Elemente einfügen. Und das sogar an eine beliebige Stelle in konstanter Zeit. Schneller ist es aber, einen vector mit resize gleich auf die richtige Grösse zu bringen und dann die Elemente zu verwenden, so wie im vorliegenden Beispiel. Das ist dann wirklich viel schneller, als eine list.
Selbst der Zugriff auf ein Element (über einen iterator) in einem list ist eher langsamer als in einem vector. Ein Iterator auf eine list ist eine Klasse, die auf den Knoten der verketteten Liste zeigt. Greife ich auf das Element zu, liefert der Iterator das Element, auf das der Knoten verweist. Ein Iterator auf ein vector ist in der Regel ein einfacher Zeiger. Und eine Zeigerdereferenzierung ist sicher einfacher, als das, was der Listeniterator machen muß.