C# Performance variablen oder Klassen übergeben

[Zespire]

Folgendes Beispiel …

public class Foo
{
	int[,,] a;
	int[,,] b;
	int[,,] c;

	public void Dostuff(Foo foo)
	{
		for(int i = 0; i < 10; i ++)
		{
			foo.a[i,i,i] = 0;
		}
	}

	public void Dostuff(int[,,] array)
	{
		for(int i = 0; i < 10; i ++)
		{
			array[i,i,i] = 0;
		}
	}
}

Macht es in Sachen Leistung irgend einen unterschied ob ich die Klasse Foo oder das Feld a übergebe ?

 

[Bagbag]

Nö

 

[Zespire]

Danke jetzt kann ich Nachts wieder ruhig schlafen.

 

[Slurpee]

Nein, es wird so oder so nur eine Referenz übergeben.

 

[Zespire]

Dessen bin ich mir bewusst aber sind es beim ersten nicht zwei pointer oder macht der Compiler da gleich den Verweis zum Array?

 

[Bagbag]

Ja schon, aber den Unterschied wirst du praktisch nicht mal messen können.

 

[Slurpee]

Ist völlig irrelevant. Fang bloß nicht an, aus Performancegründen Aufrufe zu reduzieren, das endet nur in Spaghetticode.

Generell in Bezug auf Performance:

1. Verbessere den Algorithmus, nicht die Implementierung. Die Erfahrung zeigt, dass du nur in seltenen Fällen überhaupt etwas rausholen
kannst und wenn doch, verschlechterst du mit hoher Warhscheinlichkeit die Lesbarkeit.

2. Lass es, vor allem während der Implementierung. In 9 von 10 Fällen hat das was du umbaust, rein gar nichts mit deinem Performanceproblem zu tun (Wenn du überhaupt eins hast). Implementier zu Ende und dann mach ein vernünftiges Performanceprofiling.
Dann siehst du genau, wo dein Programm tatsächlich die meiste Zeit verbringt und kannst gezielt daran arbeiten.

 

[benneq]

Die VM, die den Code ausführt, wird nach ein paar Durchläufen eh den Code neu kompilieren und optimieren (ähnlich wie in der Java VM).

Oberste Priorität beim Code lautet: Lesbar! Völlig egal welche Sprache.

Soll heißen: Achte darauf, dass die Methoden an sich, deren Namen und deren Parameter Sinn ergeben! Und schreib lieber 2-5 einfache / kurze Methoden, statt einer Methode, die 150 if-else-switch-while-do-repeat-default Statements enthält.

Wenn dann alles wie gewünscht läuft: So lassen und freuen, dass man gut wartbaren Code hat.

Erst wenn das Programm (fast) fertig ist, kümmert man sich um die Performance. Und zwar auch NUR dann, wenn es Probleme gibt. Es gibt ganz wenige Ausnahmen, wo es andersherum läuft, wie z.B. bei IoT und anderen Embedded Systems.
Für alle Systeme, bei denen man variable Hardware hat und mit einem Fingerschnipp die Performance verdoppeln kann, sollte man das mit der Optimierung ganz hinten anstellen. Doppelte Hardwarekosten sind ziemlich harmlos im Vergleich zu einem verzehnfachten Wartungsaufwand, nur weil der Spaghetticode performanter ist, aber dafür halt auch unlesbar und fragil.

 

[Zespire]

Ist völlig irrelevant. Fang bloß nicht an, aus Performancegründen Aufrufe zu reduzieren, das endet nur in Spaghetticode.

Das hatte ich nicht vor...

Ich wollte es einfach nur wissen deshalb auch die Frage ob es irgend einen Unterschied macht nicht ob es Sinn machen würde dahin gehend irgend etwas an zu passen.

 

[heulendoch]

Die VM, die den Code ausführt, wird nach ein paar Durchläufen eh den Code neu kompilieren und optimieren (ähnlich wie in der Java VM).

Hast du dazu eine Quelle? Der Compiler optimiert den Code, nach der Kompilierung wird der Code afaik nur noch ausgeführt.

 

[The Ripper]

Ich weiß aber nicht, ob das offiziell im Einsatz ist: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7702&rep=rep1&type=pdf

 

[benneq]

Stimmt, da haben sich wohl ein paar Gehirnwindungen kurzgeschlossen

Die VM in .NET kompiliert den IL Code (quasi Äquivalent zu Java ByteCode) beim Ausführen des Programms einmalig. Also super simples Konzept.

Die VM in Java arbeitet im Normalfall erst mal als Interpreter und schaut dann nach und nach welche Funktionen häufig benutzt werden und kann dann in verschiedenen Stufen den ByteCode in Maschinen Code übersetzen. Dabei sind dann sogar Optimierungen möglich, die ein Compiler VOR der Laufzeit gar nicht machen kann.

Z.B. ein einfaches `if(DEBUG == true) { ... }` kann die JVM komplett aus dem Maschinen Code streichen, wenn sich der Wert von DEBUG nicht ändert. Falls sich der Wert dann doch irgendwann mal ändern sollte, wird der Code neu kompiliert.

Genau so kann die JVM den kompilierten Code auch wieder wegwerfen, falls die Funktionen länger nicht mehr benutzt wurden.

Hängt natürlich auch von den 5 Millionen möglichen JVM Parametern ab, wie wann und was passiert

 

[heulendoch]

Achso, bei der JVM. Dachte ich hätte bei .NET komplett was verschlafen.

 

[Zespire]

Ich weiß aber nicht, ob das offiziell im Einsatz ist: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7702&rep=rep1&type=pdf

Macht nicht genau das die branch prediction der cpu in Echtzeit?

 

[Fonce]

Die VM in .NET kompiliert den IL Code (quasi Äquivalent zu Java ByteCode) beim Ausführen des Programms einmalig. Also super simples Konzept.

Naja, das ist richtig und falsch zugleich. Die VM von .NET kompiliert den IL Code beim ersten ausführen des Programms passend zur Architektur auf der er ausgeführt wird, das ist richtig. Die VM von .NET hat aber ebenfalls einen JIT Compiler welcher zur Laufzeit nach Stellen schaut welche optimiert werden können.

 

[benneq]

Das ist mir neu. Aber gut möglich. Ich hab mich schon länger nicht mehr mit .NET und der VM beschäftigt.