// Variante 1
for (int i=0; i<10; ++i)
{
    std::string str = Foo.getString();
    std::cout << str << std::endl;
}

oder ist dies besser:

// Variante 2
std::string str;
for (int i=0; i<10; ++i)
{
    str = Foo.getString();
    std::cout << str << std::endl;
}

Ich finde Variante 1 leserlicher, bin mir nicht sicher, vielleicht optimiert der Compiler Variante 1 ohnehin zu Variante 2...

for(unsigned int i = 0; i != 10; ++i)
  foo.bar();

wenn i soll nach der beendigung der schleife wieder aus dem speicher entfernt werden. und wenn du deinen string nun danach nicht mehr brauchst... dann schaut das so aus:

for(unsigned int i = 0; i != 10; ++i){
  std::string str(Foo.getString()); // bei initalisierung den c'tor verwenden und nicht die zuweisung :)
  std::cout << str << std::endl;
}

Mal davon abgesehen wird sowohl bei

std::string str(Foo.getString());

als auch bei

std::string str = Foo.getString();

der Copy-Ctor von std::string aufgerufen. Beide Varianten sind äquivalent.

Meine Frage ist aber ob die str Variable bei jeder Iteration neu auf dem Stack angelegt wird, oder ob der Compiler das auf Variante 2 optimiert?

MfG SideWinder

Das kommt wohl auf den Compiler an

MfG SideWinder

Eigentlich nicht, da Scopes zu den garantierten Verhaltensweisen gehören.

Variante 1
0x22ff40: ctor
0
0x22ff40: dtor
0x22ff40: ctor
1
0x22ff40: dtor
0x22ff40: ctor
2
0x22ff40: dtor
0x22ff40: ctor
3
0x22ff40: dtor
0x22ff40: ctor
4
0x22ff40: dtor

Variante 2
0x22ff40: ctor
0
1
2
3
4
0x22ff40: dtor

Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

Dies ist ein weit verbreiteter Irrtum, dass dies zu langsameren Code führen muss!

Die Variante 1 (innen) ist nicht nur besser lesbar sondern ist auch der schnellere Code. Fülle ich den String mit 1000 Zeichen und erhöhe die Anzahl der Durchläufe von 10 auf 10000, so braucht die Variante 1 (innen) nur 14msec - die Variante 2 (außen) aber 17msec.
Meiner Meinung nach liegt das daran, das in Variante 1 eben weniger (!) Kopien des Strings gemacht werden - wegen der 'Return Value Optimization'. Die ist genau dann möglich, wenn der String nach der Rückgabe aus 'getString()' erst angelegt wird.

Gruß
Werner

Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

ist aber nur blöd bei c++ objekten, die konstruktoren/destruktoren aufrufen. bei einfachen typen wie int/long/char usw. macht das nix.

Tachyon schrieb:

Die Variante 2 ist besser, da bei der ersten Variante bei jedem Durchlauf Objekte auf dem Stack konstruiert und wieder zerstört werden müssen.

Dies ist ein weit verbreiteter Irrtum, dass dies zu langsameren Code führen muss!

Die Variante 1 (innen) ist nicht nur besser lesbar sondern ist auch der schnellere Code. Fülle ich den String mit 1000 Zeichen und erhöhe die Anzahl der Durchläufe von 10 auf 10000, so braucht die Variante 1 (innen) nur 14msec - die Variante 2 (außen) aber 17msec.
Meiner Meinung nach liegt das daran, das in Variante 1 eben weniger (!) Kopien des Strings gemacht werden - wegen der 'Return Value Optimization'. Die ist genau dann möglich, wenn der String nach der Rückgabe aus 'getString()' erst angelegt wird.

Gruß
Werner

Hmm, sowohl mit gcc als auch mit msvc ist bei mir die Innen-Variante deutlich langsamer. Ca. Faktor 4 mit MSVC und ca. Faktor 5 bei g++.

in Zeile 48 fehlt noch die Ausgabe, dass hier ein 'int' zugewiesen wird, und in Zeile 105 und 115 darf es nicht

xINT x;
        x = i;

heißen sondern

xINT x = getXInt();

mit

xINT getXInt() { return xINT(); }

dann sieht der Output zwichen den Varianten etwas ausgeglichener aus.

Nämlich:

Variante 1
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor
0012FF60: ctor
1245120
0012FF60: dtor

Variante 2
0012FF5C: ctor
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151
0012FF64: ctor
0012FF5C: op= von 0012FF64
0012FF64: dtor
4200151

.. und plötzlich ist viel mehr Aktion bei Variante 2 !

Gruß
Werner

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

LordJaxom schrieb:

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

(Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? )

Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

Tachyon schrieb:

LordJaxom schrieb:

Du hast selbstverständlich den Releasemodus mit allen Optimierungen ausprobiert, oder?

Nein, ahbe ich nicht. Um an sowas zu denken, bin ich zu dämlich.

Entschuldige, das wusste ich natürlich nicht. Kannst Du das in Deine Signatur schreiben? Dann sieht man es gleich und muss nicht fragen...

(Muss ich noch einen Smiley anbringen, um den humoristischen Charakter dieses Statements zu entschärfen? )

Sorry, ich habe meinerseits den Smily unterschlagen.

Immerhin scheinst Du auch einen Unterschied feststellen zu können. Ich habe hier einen relativ lahmen Firmenrechner mit einem P4. Vielleicht erklären sich daraus irgendwelche Unterschiede.

Spaß beiseite: Nicht nur Neulinge, auch erfahrene Forenbesucher dürfen gerne jegliche potentiell hilfreichen Angaben machen, um ein Problem oder eine Lösung nachzuvollziehen. Mich interessiert das Thema und natürlich auch Dein Test, sonst hätte ich nicht nachgefragt. Allerdings komme ich bei meinen lokalen Tests nur auf Faktor 1,5 - 2 (MSVC++ 8.0), da wäre es schon schön die Unterschiede zu kennen.

Hallo LordJaxom,

mein Code sieht so aus:

// includes ..
struct S
{
    std::string getString() const
    {
        return std::string( 1024, 'x' );
    }
};

int main()
{
    S Foo;
    sam::Watch uhr;
    std::cout.setstate( std::ios_base::failbit );
    {
        sam::Watch::Stopper stopper(  uhr );
        // std::string str;
        for (int i=0; i<10000; ++i)
        {
            std::string str = Foo.getString();
            std::cout << str << std::endl;
        }
    }
    std::cout.clear();
    std::cout << "benötigte Zeit. " << uhr << std::endl;
    return 0;
}

damit erreiche ich das Verhältnis 17msec für Variante 1 und 20msec für Variante 2 (MS-VC8). Die zuerst genannten Werte (14msec zu 17msec) erreiche ich mit einem leeren std::ostream.

Die Zeitmessung geschieht mit dem 'QueryPerformanceCounter' aus der WinAPI (Code nicht gepostet).

Ich denke, es hängt viel davon ab, wie die Funktion aussieht, die den String liefert.

Gruß
Werner

Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

Was hat das mit der Executable zu tun?
Die innenvariante ist die schnellere wenn man sie nicht explizit aushebelt wie es erhard getan hat.

Ich denke, es hängt viel davon ab, wie die Funktion aussieht, die den String liefert.

Das denke ich auch. Ich habe jetzt auch eine Version gebastelt, wo beide Varianten identische Ergebnisse liefern.
Wenn man direkt aus einem std::string kopiert sieht es wieder ganz anders aus.

Tachyon schrieb:

Es gibt einen Fall, in dem beide Varianten gleich schnell sind, und zwar dann, wenn ich beide Varianten zusammen in ein Executable packe. Erstelle ich aber für beide Varianten getrennte Executables, ist die "Innen"-Variante immer langsamer als die "Außen"-Variante.

Was hat das mit der Executable zu tun?
Die innenvariante ist die schnellere wenn man sie nicht explizit aushebelt wie es erhard getan hat.

Das hat damit zu tun, wie und ob vor einer Variante schon Speicher allokiert wurde, oder nicht.

Das hat damit zu tun, wie und ob vor einer Variante schon Speicher allokiert wurde, oder nicht.

Äh... nein.

Die innen Variante ist nur abhängig von der RVO. Wenn RVO funktioniert ist die innenvariante schneller oder gleichschnell. Wenn RVO nicht funktioniert ist sie langsamer.

RVO heisst, dass man exakt N ctor und N dtor aufrufe hat (in der schleife) unabhängig von den externen faktoren.

wenn keine RVO funktioniert, hat man N ctor aufrufe, N copyctor aufrufe und 2*N dtor aufrufe.

während es bei der aussen variante 1 ctor, N op=, N ctor, N+1 dtor aufrufe sind.

und das hat nichts mit der funktion zu tun die die daten liefert - sofern sie ein passendes objekt liefert und wir keine konvertierungen haben. denn dann wird es komplex.

Das mit der Schleife mit dem string war nur ein vereinfachtes Beispiel. Genau genommen habe ich eine 2D Vektor Klasse, wo ich bei einem Vektor eine Komponente verändern will.

Ich habs mal getestet, alle vier Varianten bringen keine nennenswerten Unterschiede bei mir:

#include <iostream>
#include <windows.h>

using namespace std;

class Vector2D
{
public:
	Vector2D(int x_ = 0, int y_ = 0) : x(x_), y(y_) {}
	int getX() { return x; }
	int getY() { return y; }
	void setX(int newx) { x = newx; }
	void setY(int newy) { y = newy; }
	int x, y;	// zum Testen public
};

Vector2D& getSomeVector()
{
	static Vector2D s_foo(1,2);
	return s_foo;
};

int main()
{
	const long LOOPCOUNT = 1000000;
	cout.setstate( ios_base::failbit );

	// Variante 1 (innen)
	DWORD startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		Vector2D myVec = getSomeVector();
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 1 (innen) brauchte:   " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 2 (aussen)
	Vector2D myVec;
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec = getSomeVector();
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 2 (aussen) brauchte:  " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 3 (set/get)
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec.setY (getSomeVector().getY());
		myVec.setX (3);
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 3 (set/get) brauchte: " << (GetTickCount ()-startticks) << "ms" << endl;
	cout.setstate( ios_base::failbit );

	// Variante 4 (member)
	startticks = GetTickCount ();
	for (int i = 0; i < LOOPCOUNT; ++i)
	{
		myVec.y = getSomeVector().y;
		myVec.x = 3;
		cout << myVec.getX () << endl;
	}
	cout.clear();
	cout << "Variante 4 (member) brauchte:  " << (GetTickCount ()-startticks) << "ms" << endl;
	return 0;
}

So wie es ausschaut bleibe ich bei der Innenvariante. Ist klar, verschmutzt keinen Scope und ist schnell genug

using namespace std;

	for(int i = 0; i < 100; ++i)
	{
		string s;

		cout << s.capacity() << '\n';

		s += string(50, 'a');
	}

using namespace std;

	string s;

	for(int i = 0; i < 100; ++i)
	{
		s.clear();

		cout << s.capacity() << '\n';

		s += string(50, 'a');
	}