ich wüste gerne wie hoch der Anteil von Methodenaufrufen innerhalb einer Methode zu anderen Methoden der selben Klasseninstanz in Relation zu allen Methoden/Funktions-Aufrufen in einer Methode ist.

Hintergrund ist: ich entwickle zur zeit die Calling-Convention für eine neue CPU-Architektur und bin dabei auf die Idee gekommen das man den this-pointer (ist ja ein verstecktes Parameter) speziell behandeln könnte und ihn als callee-save deklariert. Wenn eine Klassen-Methode nur (Leaf-)Methoden aus der selben Klassen-Instanz aufrufen würde hätte das einen gewissen Performance-Vorteil da diese Methode das entsprechende Register gar nicht anfassen müsste. Diese Situation ist aber sicher nur bei Container-Klassen u.ä. realistisch und dort wird der Compiler sicher oft inlinen so das Calling-Conventions eh keine Rolle spielen. Wenn aber eine Methode vorwiegend Methoden anderer Klassen oder Instanzen (oder C-Funktionen) aufruft dann müssten alle aufgerufenen Methoden das entsprechende Register sichern (bei C-Funktionen natürlich die aufrufende Methode selber) ohne das die aufrufende Methode davon was hat. Daher meine Frage nach der Häufigkeit.

Es währe schön wenn mal ein paar Leute über ihre realen Applikationen schauen würden und mir ungefähr sagen könnten wie häufig es ist das eine Methode andere Methoden der selben Instanz aufruft. Dann hätte ich einen Ansatzpunkt ob sich eine Sonderbehandlung des this-Pointers lohnt oder eher kontraproduktiv ist.
Schonmal vielen Dank im Voraus!

Grüße
Erik

Es währe schön wenn mal ein paar Leute über ihre realen Applikationen schauen würden und mir ungefähr sagen könnten wie häufig es ist das eine Methode andere Methoden der selben Instanz aufruft. Dann hätte ich einen Ansatzpunkt ob sich eine Sonderbehandlung des this-Pointers lohnt oder eher kontraproduktiv ist.

Das hängt komplett vom Programmierstil ab. Beispiel: Entwickler A hat fast nur public Methoden, die sehr lang sind und ähnlicher Code wird einfach per Copy&Paste ausgeschnitten, in neue Methoden eingefügt und den Bedürfnissen angepasst. Derartiger Code hat wenig bis garkeine Klasseninternen Methodenaufrufen, ist schwer wartbar und unübersichtlich.
Entwickler B hat als Methoden fast ausschließlich kurze Methoden mit maximal 5 Zeilen, dafür aber langen und aussagekräftigen Namen, ein Verhältnis von privaten zu public Methoden von 10:1 und fast jede Methode ruft mindestens eine andere private Methode auf.
Die beiden sind Extreme, in der Realität wird allerdings alles was dazwischen liegt angetroffen. Gerade älterer Code tendiert meiner Erfahrung nach eher zum ersten Extrem, wer "Clean Code" von Rober C. Martin gelesen hat und mit dem was dort steht einverstanden ist, wird meistens einen Kompromiss zwischen Faulheit/nötiger Zeitersparnis und Extrem B eingehen.

Soviel zur nicht vorhandenen groben Abschätzung. Was das Bacuhgefühl angeht: was du machen möchtest ist eine Art der Optimierung - und da haben Bauchgefühle rein garnichts zu suchen. Ich bin aber sicher dass es Codeanalyse-Tools gibt die dir deine Frage für deinen Code beantworten können.

pumuckl schrieb:

Soviel zur nicht vorhandenen groben Abschätzung.

Mit so einer Antwort hatte ich fast gerechnet. Ich Danke Dir für Deine, sicherlich treffende, Beschreibung der Ist-Situation.

pumuckl schrieb:

Was das Bacuhgefühl angeht: was du machen möchtest ist eine Art der Optimierung - und da haben Bauchgefühle rein garnichts zu suchen.

Das Problem ist das Calling-Conventions schon recht strikt eingehalten werden sollten, da kann der Compiler nicht jedes mal nach Lust und Laune (oder irgendwelchen Code-Analysen) entscheiden wie er das handhaben will. Ich muss also vorher eine feste Entscheidung treffen die dann bindend ist. Das Zweite Problem ist das diese Optimierung ins Gegenteil umschlägt wenn sie nicht nötig ist. Ich könnte also Performance gewinnen, wenn der Code passend gestaltet ist (Extrem B), aber wenn der Code anders aussieht (Extrem A) dann wird es oft sogar Performance kosten, in Relation zur Situation wenn ich diese "Optimierung" nicht machen würde. Daher versuche ich also herauszubekommen welche Variante nun häufiger ist um dann eine Kosten-/Nutzen-Analyse machen zu können. Momentan sieht es aber eher so aus das ich diese Optimierung wohl besser lassen sollte. Außerdem könnte Link-Time-Optimization wahrscheinlich mehr herausholen.

pumuckl schrieb:

Ich bin aber sicher dass es Codeanalyse-Tools gibt die dir deine Frage für deinen Code beantworten können.

Dafür habe ich (noch) zu wenig eigenen C++-Code fabriziert als das da eine verwertbare Aussage entstehen könnte.

Grüße
Erik

Das Problem ist das Calling-Conventions schon recht strikt eingehalten werden sollten, da kann der Compiler nicht jedes mal nach Lust und Laune (oder irgendwelchen Code-Analysen) entscheiden wie er das handhaben will. Ich muss also vorher eine feste Entscheidung treffen die dann bindend ist. Das Zweite Problem ist das diese Optimierung ins Gegenteil umschlägt wenn sie nicht nötig ist. Ich könnte also Performance gewinnen, wenn der Code passend gestaltet ist (Extrem B), aber wenn der Code anders aussieht (Extrem A) dann wird es oft sogar Performance kosten, in Relation zur Situation wenn ich diese "Optimierung" nicht machen würde. Daher versuche ich also herauszubekommen welche Variante nun häufiger ist um dann eine Kosten-/Nutzen-Analyse machen zu können. Momentan sieht es aber eher so aus das ich diese Optimierung wohl besser lassen sollte. Außerdem könnte Link-Time-Optimization wahrscheinlich mehr herausholen.

Wie Pumuckl bereits erklärt hat, hängt das sehr stark vom Programmierer ab. Wenn du solch eine Entscheidung treffen musst, die sich negativ auf bestimmte Programmiertechniken auswirkt, dann gib einen Performanceguide für deine CPU heraus. Den lesen sich dann die Compilerhersteller durch und versuchen bei der Codeoptimierung alles so hin zu biegen, dass es für deine CPU passt, egal was der Programmierer gemacht hat.