3. ifstream zu langsam?

ifstream zu langsam?

  • T

    Hallo,

    Immer noch am basteln meines kleine Parsers. Er läuft jetzt, aber zu langsam. Ich benutze iftream, um formatiert zeilenweise einzulesen. Wie funktioniert iftream eigentlich? Wird dort auch gepuffert eingelesen(die geringe Plattenaktivität während des Parsens würde eigentlich darauf hindeuten). Ich springe intern von Tag zu Tag, also auch, wenn ich dazwischen das Parsen ausknipse und nur von Entity - Tag zu Entity Tag springe ist das zeimlich zerrig.
    Ansonsten wäre es auch eine kleinigkeit alles erst komlett einzulesen und gleich im Speicher zu parsen (wollte der STL halt mal 'ne Chance geben und auf direkte API - aufrufe verzichten ).

    Vielen Dank,

    TheBigW

    0
  • K

    Wie verwendest Du denn die ifstreams ?

    0
  • T

    öhm, der ifstream wird in einer Load - Funktion istanziiert, und dann als Referenz von Parse - Funktion zu Parsefunktion weitergereicht und dort wird ganz normal eingelsesen:

    void LeseWas( ifstream* pReadStream, ..... )
{
   *pReadStream >> DxfTag::m_ReadBuff; //DxfTag::m_ReadBuff ->statischer Lespuffer
   .......
}

    getline() ist auch nicht schneller (woher auch), Bottleneck ist also scheinbar ifstream. Ich würde ja anfangen das Parsing umzustricken, so daß es komplett im Speicher abläuft, würde das aber gerne vermeiden.

    0
  • S

    hin und herspringen ist ungünstig. Lieber alles in den RAM mappen (da bietet dein OS sicher sehr schöne Funktionen dafür) und dann direkt im RAM arbeiten.

    Es sei denn deine Files sind zu groß, dann musst du tricksen und immer nur den aktuellen Teil im RAM halten - dabei immer schön die Pagesize deines OS beachten.

    0
  • T

    Huhuhu und ich wollte mal komplett bei der STL bleiben *schniff*. So groß sind die Files eigentlich micht (64MB) - Fürs Parsen schon 'ne ganze Menge.

    hin und herspringen ist ungünstig. Lieber alles in den RAM mappen (da bietet >dein OS sicher sehr schöne Funktionen dafür) und dann direkt im RAM arbeiten.

    Ist mir schon klar, hatte aber den verdacht, das ifstream intern auch irgenwie im RAM puffert, da sich auf der HD beim parsen verdammt wenig tut. Werd mal schauen....

    0
  • H

    wollte der STL halt mal 'ne Chance geben und auf direkte API - aufrufe verzichten

    Seit wann gehören ifstreams zur STL?

    Mal so nebenbei: Welchen Compiler verwendest du und welche Standardlib-Implementation?
    Falls du den VC 6.0 mit der mitgelieferten Dinkumware-Lib verwendest, solltest du auf jeden Fall den fstream-Header gemäß Anleitung fixen. Ohne den Fix sind die fstreams höllen langsam.

    Letztlich sind die fstreams von Haus aus aber nicht unbedingt für ihre unglaubliche Performance bekannt. Wenn's um beste Performance geht, wirst du um die speziellen Funktionen deines BS wohl nicht drum rum kommen.

    Das muss dich natürlich keinesfalls davon abhalten die STL zu verwenden.

    0
  • S

    TheBigW schrieb:

    Huhuhu und ich wollte mal komplett bei der STL bleiben *schniff*. So groß sind die Files eigentlich micht (64MB) - Fürs Parsen schon 'ne ganze Menge.

    64MB ist doch ne ganze Menge. Das kommt je nach Anwendung darauf an - uU ist es besser das Ding zu splitten.

    Ist mir schon klar, hatte aber den verdacht, das ifstream intern auch irgenwie im RAM puffert, da sich auf der HD beim parsen verdammt wenig tut. Werd mal schauen....

    Natürlich puffert ifstream. Aber nicht effizient genug dass du durch die Gegend springen kannst. Denn das springen kostet enorm zeit - bedenke: wenn er für deinen Sprung einen Plattenzugriff braucht, bei dem er auch noch suchen muss. Du dagegen kannst einfach Blockweise arbeiten.

    Einfach die Datei in 10 Blöcke oder so teilen. Du weisst exakt die größe eines Blocks. Du weisst also genau in welchem Block welches Byte liegt. Wenn du nun einen Block verlässt, weil du aus ihm heraus springst, ladest du einfach den passenden Block nach - ohne suche, einfach mappen.

    Da kann ifstream nicht mithalten. Denn ifstream wurde für sowas ja auch nicht konzipiert.

    0
  • T

    Noch ein abschließendes Statement - ich hab das ganze ja jetzt fertig.

    Ich lese jetzt komplett alles (mittels Winapi - Funktionen ) ein und parse im Speicher. Bei der ersten Näherung kam dann raus, das es nicht an der Performance von ifstream gelegen hat, sondern an meinem ineffizienten Parser (mittlerweile gefixt).

    Was lerne ich daraus - bevor ich das nächste mal über die Performance von Implementierungen mecker schau ich mir lieber meinen eigenen Sch** nochmal genauer an :).

    Vielen Dank für eure Hilfe,

    TheBigW

    0
  • R

    jo, Profiler helfen 🙂

    (übrigens kannst du die streams weiter benutzen, du kannst ja auf Basis von Memory-Map Funktionen dein eigenen Streambackend schreiben (siehe std::stream_buf))

    0
Anmelden zum Antworten