STLangsam

Kanns sein daß die STL scheiß-langsam ist?

Shade Of Mine

scheißer schrieb:

Kanns sein daß die STL scheiß-langsam ist?

Nein, das kann nicht sein.
Aber es kann durchaus sein, dass eine bestimmte STL Implementierung 'scheiß-langsam' ist. Wobei es dann meistens aber an dem Programmierer liegt.

junix

Vor Allem die MSVC6-STL-Implementation ist sehr langsam, speziell wenns um filestreams geht... bei containern und dynamischen arrays kann man die geschwindigkeit mit vorallozieren stark erhöhen.

-junix

Hab nämlich ne eigene String-Klasse geschrieben die im Speedtest so ungefähr bei jeder Funtkion 4 mal schneller ist und das hat mich schon bicßhen gewundert wo doch die umständliche Bedienung der STL meist dadurch gerechtfertigt wird, daß sie ja ach so toll effizient und schnell wäre

aber gut wenns an microdoof liegt solls mir auch recht sein:)

Shade Of Mine

scheißer schrieb:

Hab nämlich ne eigene String-Klasse geschrieben die im Speedtest so ungefähr bei jeder Funtkion 4 mal schneller ist

Diese Klasse wuerde mich interessieren. Kannst du sie hier posten? Das waere sehr nett!

kann ich, is aber zum teil ziemlich dirty hack und ich kann auch nicht garantieren daß nicht einige Fehler drin sind (is nämlich erst in Arbeit, falls sie je fertig wird, war mehr so n test):

#define CAP 100
#define EXTRA_SPACE 50

template <class Char> class String
 {
   private:
		Char*str;
		Char stat[CAP];
		Char*dyn;
		int len;
		int cap;

	void memMan(int want)   //managt Speichersaches
	{

		if (cap<want)  //cap wird auf die neue Anforderung + extra space gesetzt
		{	
			Char*temp=str;
			cap=want+EXTRA_SPACE;
			dyn= new Char[cap];
			write(dyn,temp);
			if (str!=stat)
				delete[] temp;
		}	
	}

	static void write(Char*dest,const Char*src)
	{

		for ( ; (*src) ; ++dest,++src)
		{
			*dest=*src;
		}
		*dest=0;
	}

	static void write(Char*dest, const Char*src,int l)
	{
          for (int i=0 ;  i<l ; ++dest,++src, ++i)
		  {
			  *dest=*src;
		  }
		  *dest=0;
	}

	 static int arrayStringLen(const Char* c)
	{
		for (const Char*p=c;  ; ++p)
             if (!*p)
		        return  p-c;	
	}

	void set(const String&copy)
	{
		int l=copy.len;
		memMan(l);
		write(str,copy.str);
		len=l;

	}

	void set(const Char*copy)
	{
		int l=arrayStringLen(copy);
		memMan(l);
		write(str,copy);
		len=l;

	}

	void append(const Char*app)
	{

		int l=arrayStringLen(app);
		int gesLen= l+len;
		memMan(gesLen);
		write(str+len,app);
		len=gesLen;

	}

	void append(const String&app)
	{
		int l=app.len;
		int gesLen= l+len;
		memMan(gesLen);
		write(str+len,app.str);
		len=gesLen;
	}

	void appendThisSelf()
	{
		int l=len+len;
		memMan(l);
		write(str+len,str,len);
		len=l;

	}

   public:

    int length() const
	{
		return len;
	}

	String() : str(stat), dyn(0), len(0),cap(CAP)
	{
		*str=0;
	}
	String (const String&copy) : str(stat), dyn(0), cap(CAP)
	{
		set(copy);
	}
	String(const Char*copy) : str(stat), dyn(0),cap(CAP)
	{
		set(copy);
	}

	const String& operator+=(const String&app)
	{
		if (&app==this) appendThisSelf();
		else append(app);
		return *this;
	}

    const String& operator+=(const Char*app)
	{
		if (app==str) appendThisSelf();
		else append(app);
		return *this;
	}

    const String& operator=(const String&copy)
	{
		if (&copy==this) return *this;
		set(copy);
		return *this;
	}

	const String& operator=(const Char*copy)
	{
		if (copy==str) return *this;
		set(copy);
		return *this;
	}

	bool operator==(const Char*c) const
	{
		if (str==c) return true;
		if (len!= arrayStringLen(c)) return false;
		for (Char*p=str,*o=c; ; ++p,++o)
		{
			if (*p!=*o) return false;
			if (!*p) return true;
		}
	}

	bool operator==(const String&s) const
	{
		if (this==&s) return true;
		if (len!=s.len) return false;
		for (Char*p=str,*o=s.str; ; ++p,++o)
		{
			if (*p!=*o) return false;
			if (!*p) return true;
		}
	}

	const Char* asArrayString() const
	{
		return str;
	}

 };

p.s. me

Walli

Sieht irgendwie sehr unsicher aus alles. Darf man denn mal nach den Testbedingungen fragen? Wieviele Durchläufe? Welche verschiedenen Stringlängen im Test? Wurde der Vergleich mit std::string im Release getestet?

Probiers doch selber aus! In der derzeitigen Form knallts nur hin und wieder mal ich hab einiges probiert und natürlich release (in msvc)

s raffinierte an der klasse ist, daß nichts dynamisch (langsam) allokiert wird, solange string.length nicht über 100 geht

HumeSikkins

@Shade
Wenn du so ne hässliche Referenz-gezählte Stringklasse hast, dann ist 4 mal schneller gar kein Problem. Besonders wenn du in einem ST-Programm gegen die MT-Version linkst. Die string-Implementation der Dinkumware-Lib die beim VC 6.0 mitgeliefert wird ist performancemäßig schon sehr arm. Da sind also Reserven, falls ein Profiler einen mal auf diesen Flaschenhals hinweisen sollte.

PS: Zur Theorie zum Thema COW-String siehe Herb Sutters Webseite.

@junix
Die Firma Dinkumware erklärt auf ihrer Webseite wie man den fstream-Header fixen muss, damit die Streams nicht mehr ganz so schnarch lahm sind (alternativ kann man auch meinen STLFix runterladen). Danach hat man zwar nicht ganz die Performanz der BS-Aufrufe, man kann aber vernünftig mit den Streams arbeiten.

Shade Of Mine

Ich habe lange nicht mehr mit dem VC++6 gearbeitet - und selbst da hatte ich STLPort installiert. Kann mich also nur an meine Messungen gegen STLPort erinnern, und da haben meine string Varianten nicht gewinnen können (immer nur für bestimmte Aufgaben - aber die generelle Performance von std::string war dort sehr gut)

Und was ich so von der neuen Dinkumware Library mitbekommen habe, da 'rult' die ja ziemlich

Auf www.stlport.org gibts im Forum irgendwo einen Performance Vergleich von std::string bei STLPort, Dinkumware und libstdc++

scheißer schrieb:

aber gut wenns an microdoof liegt solls mir auch recht sein:)

Kannst froh sein das es MS gibt du hammel, sonst hätteste heute keine so windowsähnliche KDE in Linux. Depp

peterchen

a) template-basierter code ist in debug-builds meist deutlich langsamer, bietet aber mehr Möglichkeiten für den optimizer
b) bei einem "normalen" VC6-Projekt nimmt die STL Rücksicht auf Multibyte-zeichensätze
c) Auch bei der STL muß man wissen was richtig und was falsch ist
d) Keine (mir bekannte) STL-Implementation leistet sich ein statisches Buffer von 100 Bytes - Wenn überhaupt dann ca 16.

Wenn's so klingt als würde ich die STL verteidigen, ist das natürlich nur eine Illusion

Artchi

VC++6.0 ist doch schon ur alt, kam das nicht schon so ca. 1998 raus??? Ich meine nur, rechnet mal wieviel Jahre das her ist und das dann im Computer-Zeitalter. Weiterhin solltet ihr bedenken, das VC++6.0 vor dem letzten verabschiedeten C++-Standard erschien.

Insgesamt ist VC++6.0 eines der besten IDE und Compiler zu seiner Zeit gewesen. Heute reisst es natürlich keinen Baum mehr aus... aber dafür gibts halt auch VC++2003 (7.1).

simon.phoenix

VC++ 7 ist verbuggt.

daishi

Also ich muß hier auchmal was los werden.
Ich hatte bisher ja auch bei jeder Gelegenheit die Geschwindigkeit der STL, insbesondere beim vector, in Bezug auf die dynamische änderung der Größe, bemängelt.

Ich habe mir jetzt das Service Pack 5 und das Processor Pack beim Visual Studio 6 installiert.

Nun muß ich meine Aussagen über die Geschwindigkeit der STL wiederrufen.
Die Dinger sind jetzt richtig flott.

PS: Ich bitte alles Personen hier im Forum, mit denen ich deswegen Diskussionen hatte dies zur Kenntnis zu nehmen.

Je nach aufgabe solte man vielleicht statt Strings lieber Ropes nehmen. Das aber nur so am Rande.

peterchen

@daishi: schön zu lesen

Artchi

daishi! Yo, du hast meinen Respekt das du es im Nachhinein zugibst! Wir hatten ja einigen Schlagabtasuch. Aber war auch schon damals wieder vergessen.