angenommen ich habe folgenden Code:

#include <iostream>
#include <vector>

struct foo
{
	foo() : vec3 (1000) { for (size_t i = 0; i < 1000000; ++i) { vec1.push_back(i); } for (size_t i = 0; i < 1000; ++i) { vec2.push_back(i); } }

	std::vector<double> operator()(std::vector<double> const &input)
	{
		size_t inner_counter = 0, outer_counter = 0;
		for (size_t i = 0; i < 1000; ++i) {
			for (size_t j = 0; j < 1000; ++j) {
				vec3[i] += vec1[inner_counter]*(input[j] + vec2[j]);
				++inner_counter; // Darum gehts
			}
			vec3[i] += vec2[outer_counter];
			++outer_counter;
		}
		return vec3;
	}

	std::vector<double> vec1, vec2, vec3;
};

int main()
{
	std::vector<double> input(1000);
	for (auto &i : input) {
		i = 1.0;
	}

	foo f;

	for (size_t i = 0; i < 1000; ++i) {
		f(input);
		std::cout << i << '\n';
	}
}

Wenn ich jetzt diesen Code mit dem Visual Studio 2013 Profiler auf seine Performance hin untersuchen will, zeigt mir dieser an dass 89,9% der gesamten Laufzeit bei Zeile 14 draufgeht (also der integer Addition). Zeile 13, in der ja eigentlich viel mehr passiert schlägt dagegen nur mit 9,2% zu Buche.

Woran kann das liegen? Eigentlich sollte eine simple integer Addition doch so ziemlich das schnellste sein was man machen kann oder?

Ich meine was bringt mir dann überhaupt ein Profiler wenn er mir die falschen Zeilen anzeigt und die Compiler Optimierung nicht berücksichtigt?

Aber sollte der Profiler nicht schlau genug sein das zu merken?

Wie sollte er das tun, wenn wild gemischt wird?

Ich meine was bringt mir dann überhaupt ein Profiler wenn er mir die falschen Zeilen anzeigt und die Compiler Optimierung nicht berücksichtigt?

Was bringt es dir, unoptimierten Code zu profilen?

Miss die Performance von Codeabschnitten, nicht von einzelnen Zeilen. Im schlimmsten Fall von ganzen Funktionen. Aber viele Profiler bieten auch die Option, einzelne Codeabschnitte festzulegen, die dann als Einheit betrachtet werden. Code ist immer ein Gesamtkonstrukt, wenn es um Performance geht. Wenn du wissen willst, wie lange eine Integeraddition braucht, guck im Prozessorhandbuch nach (wobei selbst dort stehen wird, dass es im Details darauf ankommt, welche Anweisungen vorher und nachher folgen). Wenn du hingegen wissen willst, ob der hier gezeigte innere Schleifencode insgesamt schneller oder langsamer ist als eine andere Variante, oder in welcher Schleife dein Programm die meiste Zeit verbraucht, dann ist ein Profiler das richtige Werkzeug.

Was bringt es dir, unoptimierten Code zu profilen?

Es ging mir nicht darum unoptimierten Code zu profilen. Aber wenn es in diesem Fall jetzt wirklich daran liegt dass die Addition durch den Compiler vorgezogen wurde, könnte ein Profiler ja mit dem Compiler reden und diese Information nutzen um zurückzurechnen dass die Zeile doch nicht so lahm ist. Das meinte ich.

SeppJ schrieb:

Wenn du hingegen wissen willst, ob der hier gezeigte innere Schleifencode insgesamt schneller oder langsamer ist als eine andere Variante, oder in welcher Schleife dein Programm die meiste Zeit verbraucht, dann ist ein Profiler das richtige Werkzeug.

Hm Schade, ich hatte gehofft dass mir der Profiler die teuersten Zeilen anzeigt so dass man gleich auf den ersten Blick sehen kann wo sich das Optimieren am meisten lohnt.