Performanceunterschiede beim push_back?

epidemic

Hallo Zusammen,

habe folgendes gemacht:
eine ca 30 MB Große Datei binär in einen Buffer eingelesen

//...Code

 // Datei öffnen zum einlesen.
    ifFStream_in.open ("c:\\SEQ.unl", ifstream::binary);

    // Abfragen ob Datei überhaupt existierte.
    if (ifFStream_in.good())
    {
            // Dateigröße bestimmen.
 ifFStream_in.seekg(0, ios::end);
        unsigned long FileSize = ifFStream_in.tellg();
        ifFStream_in.seekg(0, ios::beg);

        char *pszBuffer = new char [FileSize+1];

        ifFStream_in.read(pszBuffer, FileSize);

//Später wird dieser in eine string var kopiert
string sBuffer(pszBuffer);

         delete [] pszBuffer;

     string::size_type PosBegin=0;
     string::size_type Pos = 0;

    deque<string> dTeilstring;  
 while((Pos  = sBuffer.find("\n", Pos) ) != string::npos)
  {
    string sTemp(&sBuffer[PosBegin],&sBuffer[Pos]);

    // Teilstrings per push_back kopieren
    dTeilstring.push_back(sTemp);

     PosBegin=Pos++;
     }

//.... Code

Was mich hier gewundert hatte , die Performance war unter dem C++ Builder
super , eine ca. 30 MB Datei wurde innerhalb von ca. 3 sec. abgearbeitet.

Unter dem MVisual C++ 6 hatte ich auch einen Test gemacht, und da lief es ca.
13 sec.!

Beim Debugen stellte ich fest , daß der Unterschied am push_back lag!

Kann sich das jemand erklären ?
Verwenden die beiden Anbieter vielleicht verschiedene Versionen von den STL Biblios, vielleicht erweitert und nicht identisch mit dem Ding von HP ?

Für eine freundliche Hilfe wäre ich dankbar!

godlikebot

epidemic schrieb:

Beim Debugen stellte ich fest , daß der Unterschied am push_back lag!

Hmmm, aber für den "Benchmark" hast du das Programm doch im Release-Modus erstellt, oder? Das wär meine einzige Vermutung, wie dieser Krasse Unterschied zustande kommen könnte... Wenn's das nicht ist, bin ich auch mal auf ne Antwort gespannt ;).

bau inline in die STL ein und fertig.

Walli

Ne, wechsle die STL Implementierung (z.B. http://www.sgi.com/tech/stl/ ). Die vom 6er VC++ ist shit.

jajaja immer her mit dem shit

Ringding

Die ist ja uralt. ("has been testet with Visual C++ 5")

Wenn schon, dann gleich http://www.stlport.org/.

hau ab mit STLPort, totaler dreck und buggy

Walli

Ringding schrieb:

Die ist ja uralt. ("has been testet with Visual C++ 5")

Ach, daraus schließt du, dass sie veraltet ist? Soll ich dir mal was sagen?

STLport was reported to work with the compilers listed below.
[...]
# Microsoft Visual C++ 4.x - 6.x, for Win32

Die ist ja uralt :p . Wer weiß wie oft die ihre Kompatibilitätsliste updaten (VC++ 7.1 ist z.B. noch nicht drauf). Kann sein, dass der VC++ 6 garnicht mehr unterstützt wird. Dass der nicht gerade der standardkonformste Compiler ist brauche ich glaube ich nicht extra zu erwähnen. Fakt ist, dass die Sgi-STL darauf läuft.

shit on sgi!

Ringding

6 ist immerhin neuer als 5

Tatsache ist, dass stlport aktiv gewartet wird und dass die letzte SGI-Version aus dem Jahre 2001 (gerade noch - 2. Jänner :)) stammt.

SGI ist der Vater der STL, ist schon klar, aber stlport ist einfach mittlerweile die wesentlich bessere Alternative.

Walli

Ja, aber läuft die auch auf dem 6er? Ich glaube ehrlich gesagt nicht dran. Die Kompatibilitätsliste kommt mir ziemlich veraltet vor und ich denke auch nicht, dass die STLPort-Entwickler heute noch unbedingt Rücksicht auf den VC++ 6 nehmen. Is ja auch egal...

Ringding

Ja, natürlich ist der supported: http://www.stlport.org/doc/platforms.html

epidemic

godlikebot schrieb:

Hmmm, aber für den "Benchmark" hast du das Programm doch im Release-Modus erstellt, oder?

Klar im Release natürlich.

Jetzt bin ich mittlerweile weiter gekommen.
Gestern Abend machte ich zu Hause einen Benchmark unter Visual Studio 7.1(Anm.: 2003 er Version).
Und da lief mein Benchmark innerhalb von 1328 ms durch.

Ich schließe also daraus daß ich unter VC++ 6 veraltete STL hatte....

Danke an alle für Eure Mühe!!

ich hatte mal ein einfaches konsolenprog geschrieben was einige schleifen abarbeiten sollte, dabei habe ich festgestellt, dass compiler die auf gcc basieren wesentlich schneller laufende programme erstellten als visual 7. mit schnell meine ich allerdings nur sie startphase.