Performance eines C# Programms erhöhen

Hallo, ich habe einen sehr Rechenintensiven Algorithmus geschrieben der pro Durchlauf so ca. 30 Funktionsaufrufe beinhaltet. Die Rechnungen innerhalb dieser Funktionen sind relativ einfach. Meine Frage ist jetzt, ob es allgemeine Tipps gibt um die Performance eines Programm zu erhöhen? Z.B. arbeite ich viel mit dem Datentyp double. Wird eine Rechenoperation schneller ausgeführt wenn ich die Zahl auf 3 Nachkommastellen runde? Oder dauert sie dann sogar länger? Oder welche schleife sollte man eher verwenden? For- oder foreach-Schleife?

Ich weiß die Frage ist sehr schwammig aber vielleicht gibt es ja allgemeine Grundregeln!?

Hallo snsewill,

das Wichtigste: "premature optimization is the root of all evil" (Donald E. Knuth).
D.h. schreib den Code so dass er leserlich, wartbar und verständlich ist. Erst wenn du tatsächlich (mit einem Profiler, etc) feststellst, dass es zu langsame Passagen gibt, solltest du diese optimieren.

Weiters gilt es einen Algorithmus mit möglichst niedriger Aufwandsklasse (Big-O-Notation) zu wählen. Das hilft wesentlich mehr als Mikrooptimierungen.

wenn ich die Zahl auf 3 Nachkommastellen runde?

Die gegenwärtigen Prozessoren können alle mit double sehr gut umgehen, ein Runden ist nur zusätzlicher Aufwand und sollte tunlichst vermieden werden. Runden kannst du dann bei der Ausgabe des doubles (wenn nötig).

For- oder foreach-Schleife?

Grundsätzlich ist die for-Schleife schneller als die foreach-Schleife. Bei Arrays ist es aber egal, da der C#-Compiler aus dort aus der foreach- eine for-Schleife macht. Ein Grund mehr warum der Code leserlich erstellt werden soll, den Rest soll(te) der Compiler erledigen.

Es gibt aber ein paar Tricks mit denen der Code performanter erstellt werden kann. Suche einfach mal danach 😉 Google-Suche nach c# performance optimization

Für eine konkrete Frage könnte ich konkreter Antworten.

Wichtig ist messen, den nur aufs gute Glück hin optimieren kann schnell in die Hose gehen. Moderne Prozessoren machen mit ihren Optimierungen oft einen Strich durch Rechnun - wie z.B. bei Cache-Lines, Instruction Parallelism, usw. Daher ist das eingangs erwähnte Zitat jedenfalls zu beherzigen.
An deiner Idee mit dem Runden siehst du auch, dass der Schuss nach hinten los ginge nur weil du an "premature optimization" dachtest 😃

mfG Gü

Vielen Dank erstmal! Ich gucke mal ob ich ein genauere Fragen formulieren kann.

Hallo snsewill,

ich schließe mich den Aussagen von gfoidl in jeder Hinsicht an. Ich möchte daher zu dem Hinweis mit den Aufwandsklasse vs Mikrooptimierungen nur noch Beispiel ergänzen: Mergesort langsamer als Bubblesort? [==> Nein, Messfehler / Aufwandsklasse vs. Mikrooptimierungen].

herbivore