3. Stream extrem langsam?

Stream extrem langsam?

  • B

    mal abgesehen von allem, 30min fpr 5mb ist doch schon bischen arg lange..

    0
  • B

    Könnte man hier nicht mit stringstream::rdbuf::setbuf dem Stringstream gleich so groß machen, dass das seltener passiert?

    0
  • M

    Schreib doch direkt in die Datei

    0
  • C

    Vermutlich gar nicht (außer durch einige üble Hacks, die ich hier nicht einmal erwähnen möchte), weil der Stream dir keinen Direktzugriff auf seinen unterliegenden String genehmigt. Wie ändert sich denn die Laufzeit, wenn du direkt in einen fstream schreibst (natürlich nachdem du die unnötigen endl's ausgewechselt hast)?

    0
  • A

    Hast du mal als Gegentest die Ausgabe in den Stream weg gelassen? Also das du zwar weiterhin berechnest aber den Stream weg lässt.

    for(int i = 0; i < numLines; i++)
                {
                    cPer = (100*i)/(numLines);
                    if(cPer > lastPer)
                    {    lastPer = cPer;
                        cout << cPer << "% Done (" << (numCols*i) << " Pixels)" << endl;
                    }
                    // htmlText << "<tr height='1'>" << endl;
                    for(int j = 0; j < numCols; j++)
                    {
                       // htmlText <<  "<td width='1' height='1' bgcolor='#" << hex << 
                         int dummy = (int)pixels[(numCols*i) + j];
                    }
                    // htmlText << "</tr>" << endl;
                }

    Wie ist nun die Performance?

    0
  • P

    CStoll schrieb:

    Vermutlich gar nicht (außer durch einige üble Hacks, die ich hier nicht einmal erwähnen möchte), weil der Stream dir keinen Direktzugriff auf seinen unterliegenden String genehmigt. Wie ändert sich denn die Laufzeit, wenn du direkt in einen fstream schreibst (natürlich nachdem du die unnötigen endl's ausgewechselt hast)?

    teste ich mal aus... dauert n paar minuten

    edit:
    so... hier die ergebnisse:

    Alte methode:
    Finished and saved to file!
    19200 pixels written in 112692 milliseconds

    nur ein dummy :
    Finished and saved to file!
    19200 pixels written in 61 milliseconds

    und wenn ich direkt in die datei schreibe:
    Finished and saved to file!
    19200 pixels written in 641 milliseconds

    !!

    also direkt in die datei schreiben 😉

    thx

    edit2: na heiss:

    Finished and saved to file!
    480000 pixels written in 12550 milliseconds

    480.000 pixel in 12 sekunden, statt 19.200 pixel in 2 minuten...die stream funktion sollte vielleicht n bissel überarbeitet werden (man könnte ja vielleicht versuchen den benötigten speicher vorherzusehen, statt linear immer gleich viel dranzuhängen)

    0
  • J

    Aus diesem Grund wäre es vielleicht doch besser direkt rauszuschreiben. Dann werden die Sachen einfach auf die Platte geschoben und nicht noch umkopiert.

    edit: argh, kommt davon, wenn man zwischendrin was anderes macht 🙂

    0
  • T

    pixartist schrieb:

    naja jedenfalls hat es im nachhinein dann doch nen sinn gehabt, das ist nähmlich ein toller browserbenchmark. Ich habe dadurch rausgefunden, das Opera und der IE tabellen um nen riesigen faktor schneller darstellen können als firefox

    <img src='bg.gif'>

    du packst in jede deiner tabellenzellen ein bild, wahrscheinlich 1x1 pixel groß? das macht firefox langsam, nicht die tabelle. schreib wenigstens die größe des bildes mit ins tag.

    0
  • C

    pixartist schrieb:

    480.000 pixel in 12 sekunden, statt 19.200 pixel in 2 minuten...die stream funktion sollte vielleicht n bissel überarbeitet werden (man könnte ja vielleicht versuchen den benötigten speicher vorherzusehen, statt linear immer gleich viel dranzuhängen)

    Erstens: string's vergrößern ihren Speicher nicht linear, sondern idR exponentiell.

    Zweitens: Woher soll der Stream ganz am Anfang wissen, wieviele Daten er letztendlich benötigen wird?

    Drittens: Der Haupt-Engpass bei deinem Test wird wohl der Heap-Manager gewesen sein - 5MB kann der auch nicht so einfach aus dem Ärmel schütteln (und höchstwahrscheinlich kommst du da in Größenordnungen, wo Windows anfängt über Swapping nachzudenken).

    0
  • J

    Eine andere möglichkeit wären vielleicht auch die (deprecated) strstreams. Da muß man den Buffer selbst managen und in Deinem Fall lässt sich die benötigte Größe ja recht gut vorher abschätzen. Das könnte auch ordentlich speed bringen. Am Schluß wird dann ein einziges mal rausgeschrieben.

    0
  • A

    Welche Stdlib-Implementierung verwendest du? Ist es die von Dinkumware?

    0
Anmelden zum Antworten