Performance von Getters / Setters
-
Ich habe auch mit "Release" getestet, wurde nicht inline verarbeitet.
Ich habe mir jetzt mal eben die FAQ über inline durchgelesen, sehr interessant.@knivil: ja spielt schon eine kleinere Rolle, immerhin konnte ich die Verarbeitung nun um eine Sekunde drücken. Da diese Operationen im Batch ausgeführt werden, wird es sich schon ein wenig lohnen.
Ich werde es auch mal mit dem expliziten Inline-Argument probieren, aber eigentlich ist es so, wie ich es nun nutze, ausreichend.
-
Ich habe auch mit "Release" getestet, wurde nicht inline verarbeitet.
Wie hast Du das herausgefunden? Assembler Code angeguckt?
-
Mittels callgrind, da sehe ich das er die getter Methoden aufruft.
Das target heisst hier bei cmake "relwithdebug" und ist -O3 mit -g.
Sollte dann doch optimiert genug sein, oder etwa auch nicht?
-
TheGrudge schrieb:
Mittels callgrind, da sehe ich das er die getter Methoden aufruft.
Das target heisst hier bei cmake "relwithdebug" und ist -O3 mit -g.
Sollte dann doch optimiert genug sein, oder etwa auch nicht?Nein. Da steht doch "withdebug" - also noch mit debuginformatinen und deshalb ggf auch mit Methoden die nicht geinlined werden.
-
Denk dran, dass du unter Umständen die Debug-Laufzeitumgebung (unabhängig von Debug- oder Releasemodus!) zusätzlich deaktivieren musst, um maximale Performance zu erhalten. Beim MSVC++ zum Beispiel habe ich dadurch schon drastische Unterschiede feststellen können.
-
Muss mich hier mal kurz reinhängen !
Wo mache ich das im VS ??
-
Du kannst z.B. mit der Definition _SECURE_SCL=0 (in den Projekteinstellungen->C/C++->Präprozessor oder per #define _SECURE_SCL 0 an zentraler Stelle) sämtliche Laufzeitprüfungen der Standardbibliothek ausschalten. Damit kannst Du schon mal eine Menge gewinnen.
Am besten setzt Du diese Definiton in den Projekteinstellungen für die Konfiguration Release ein, dann hast Du eine "echte" Releasekonfiguration
-
Ah ok.
Hab ich noch nicht gewusst !Müsste also einfach
#ifndef _DEBUG #define _SECURE_SCL 0 ...schreiben.
Oder halt in den Projektsettings bei Prepocessor Definitions.Und was genau für Laufzeitprüfungen fallen da an ?
Bzw. welche Prüfungen zur Laufzeit schalte ich damit ab ?
-
TheGrudge schrieb:
@knivil: ja spielt schon eine kleinere Rolle, immerhin konnte ich die Verarbeitung nun um eine Sekunde drücken. Da diese Operationen im Batch ausgeführt werden, wird es sich schon ein wenig lohnen.
Und wie gross ist die gesamte Laufzeit des Programmes? Und wie hast du diese Zeitdifferenz gemessen? "Eine kleine Rolle" spielt eben ueberhaupt keine Rolle. 1 sek, was ist das schon im Userland? Laufen noch andere Programme im Hintergrund oder ein aktiver Dienst muss mal ein wenig was machen, dann ist der Unterschied von 1 sek anderswo zu suchen.
-
Natürlich spielt es eine Rolle, wenn ich 300 Bilder im Batch verarbeite, und es dauert 300 Sekunden länger als ohne Optimierung.
Ich habe es nun auch mit 'Release getestet', es wird nicht inline verwendet. Also muss ich es so lassen wie ich es im Moment tue (direkter Zugriff), oder es mit dem 'inline' Schlüsselwort versuchen.
Naja meine Frage wurde damit ja beantwortet, und dank das FAQ-Artikels bin ich nun auch ein wenig schlauer, was 'inline' betrifft.