Weniger Code für ein Event = bessere Performance?

Nur eine kleine Verständnisfrage. Heißt weniger Code für ein Event (z.b. Button1 click) immer, dass die befehle schneller ausgeführt werden können und dass generell die Performance der app besser wird? Kann es auch sein, dass weniger Objekte in der App die Performance verbessern? (z.b. Man hat 40 Buttons in seiner app und man reduziert diese zahl auf 10) Wenn ja hätte ich nämlich eine weitere frage, da allerdings zu einem spezifischen Code...
Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.

Hi

Nun, die Buttons werden beim Start jeweils initialisiert, also der XAML-Code geparsed und dann visuell dargstellt.
Je mehr Elemente da abgearbeitet werden müssen, desto länger geht der Appstart, das ist klar. Obwohl es nur bei sehr vielen ELementen n'Problem wird.

Nicht die Länge des Codes ist entscheidend, sondern was genau du machst. Wenn du unter Button1_Click(..,..) irgend eine Abfrage machst, kann auch ein 1-Zeiler länger gehen. Kommt halt drauf an, was genau du machst...

Gruess

Sven

ALs Faustregel kann man nehmen, dass man alles was länger als 10ms dauert in einen eigenen Thread auslagert, und das nicht im UI Thread laufen lässt. Der Code der im Event Handler des Buttons ausgeführt wird wird im UI Thread ausgeführt. Der ist auch für das anzeigen der Elemente zuständig, und wenn du den blockierst hängt die App. Das ist der Hauptgrund warum es in Silverlight bei Netzwerkintensiven Tasks keine synchronen Methoden gibt (damit es schwerer wird etwas falsch zu machen ;) )

Die Anzahl an Elementen haben natürlich einen Einfluss auf die Performance. Was meiner Erfahrung nach auch sehr entscheidend ist, ist die Anordnung. Wenn man den Objekten relative Größen gibt, so das sie sich dynamisch mit ihrem Content vergrößern oder verkleinern ist das sehr rechenintensiv. Das kommt besonders bei Listen zum tragen.

Dazu sollte man noch beachten, dass man dem OOP Prinzip von C# nach geht.
Wobei hier auch wieder zu beachten ist, dass man nur große Funktionen bzw. sinnvolle Funktionen schreibt.

Beim programmieren sollte man immer zukunfstorientiert arbeiten. Zuviele Funktionen ist schlecht für die Performance(da die Variablen immer erst kopiert werden müssen etc.), zuwenig schlecht für die Wartung/Lesbarkeit.

Und wie bereits gesagt, es kommt drauf an was du machst. Wenn du eine Funktion aufrufst ist das immer eine Sache. Du weißt nicht genau wie viel in dieser Funktion steht.
Aber normalerweise merkt man davon nicht viel. Um zu testen wie lange eine Funktion zur Ausführung benötigt ist die einfachste Variante folgende:

Code:

---

DateTime startTime = DateTime.Now;
/* ------To-Do------- */
DateTime endTime = DateTime.Now;
TimeSpan neededTime = endTime - startTime;

---

Ist zwar nicht die genauste Methode, aber es reicht um einen Ansatz zu finden.
In der Release Variante sollte das natürlich entfernt werden. Unnötige Resourcen.

Also zu den kleinen Methoden mach ich mir üblicherweise keine Gedanken, da die automatisches inlining benutzen (also die Methode beim kompilieren entfernt wird und direkt in der aufrufenden Methode eingebettet.

Üblicherweise würde ich ja ohnehin sagen: erst mal sauber implementieren, dass alles geht was gehen soll und sich dann ansehen wo Performance-Probleme sind und gezielt optimieren. Üblicherweise zahlt sich nämlich Optimierung hauptsächlich innerhalb von Schleifen aus oder an Stellen wo eben viele Objekte benutzt werden - nicht jedoch in so "Einmalgeschichten" wie Event-Handlern von Controls.

Beispiel:

Code:

---

Button_Clicked(EventArgs e) {
  command 1;
  for(int i 0; i < 10000; i++) {
    method1(i);
  }
  command2;
  command3;
}

---

Da optimierst du sicher am besten den Inhalt von method1() weil das 10000x ausgeführt wird, der Rest aber nur einmal.

Man sollte auf keinen Fall versuchen irgendwelche Dinge zu optimieren und den Code dadurch total unleserlich machen "Premature optimization is the root of all evil". Optimieren sollte man erst, wenn es notwendig ist, und wenn es zu Performance Problemen kommt. Auch würde ich die Aussage so nicht stehen lassen, dass zu viele Methodenaufrufe zu Problemen führt. Wenn es nicht mehrere Billionen sind merkt man das ja nicht mal. Die Wartbarkeit ist dabei viel wichtiger. Auch stimmt die Aussage nicht, dass bei einem Methodenaufruf die Variablen kopiert werden. Die meisten größeren Objekte sind Referenztypen und werden via call by reference übergeben, also nur ein Verweis auf das Ursprungsobjekt. Nur Wertetypen werden kopiert, und deren Größe kann man für gewöhnlich vernachlässigen.

Danke für die Antworten! Das wurde ja echt theoretisch xD
Aber ich glaube ich habe es verstanden, irgendwie stimmt es, aber dann doch nicht immer. Wenn ich mal wieder etwas mehr Zeit habe komme ich zu meinem spezifischen fall!

Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.

mein fall:
wenn ein bestimmter button ausgewählt wird, werden momentan einige andere buttons sichtbar und die buttons, die davor sichtbar waren, werden unsichtbar. die nun unsichtbaren buttons und die sichtbaren buttons haben natürlich einen unterschiedlichen code. allerdings dachte ich mir, dass es bestimmt besser ist für die performance es so umzusetzen, dass nicht immer neue buttons sichtbar werden, sondern den code der buttons mit einer if-clause zu schreiben.

also so:

if ("button1.ausgewählt") { ... }
if ("button2.ausgewählt") { ... }
...

ich dachte mir ich mache es so, aber es hat nicht geklappt:

if (button1.Background.Equals(Colors.Yellow)) { ... }

also wie setze ich das jetzt mit entweder dem "buttonx.ausgwählt" oder dem background um?

natürlich wäre es jetzt so, dass wenn man auf dem anderen button drückt, dass sich die hintergrundfarbe von button1 von gelb zu zum beispiel grün ändert.

Ich würde sagen es kommt darauf an wieviele Buttons das dann letzten Endes wären. Wenn du nicht im Ergebnis 100 Buttons hättest wird es glaub ich relativ egal sein.

Die Frage ist halt was die Buttons unterm Strich genau machen. Wenn du damit z.B. was ein/ausschaltest dann kannst du das ja in einer bool'schen Variable machen und mit einem Converter die Farbe daraus ableiten (DataBinding).

Der Button-Code würde dann recht einfach sein weil er nur enabled = !enabled; ausführen würde.

Wenn die Buttons aber verschiedene Dinge machen, dann würde ich da auch verschiedene Buttons verwenden und halt ein-/ausblenden - das führt nämlich wohl zu deutlich verständlicherem Code - weil btnEnableSkyNet_Clicked ist als Methodenname gleich viel verständlicher als button1_Clicked mit drin dann einer if/else-Ladder die sich überlegt was Button1 denn gerade eigentlich tut.

tut mir leid, aber ich hab das jetzt nicht ganz so verstanden.

bei mir würde ich 22 buttons mit jeweils einem langem code für ein event sparen, allerdings würden sich 11 andere codes verlängern. ich merke zur zeit, dass es c.a. eine halbe sekunde braucht, wenn man auf einen button drückt bis irgendetwas passiert. für den benutzer der ist das eben nicht so toll und deswegen wollte ich genau das auch verbessern. davor hatte ich c.a. 25 buttons und 2 textboxs weniger und natürlich nochmal viel weniger code und alles lief ziemlich schnell. ich habe allerdings auf eine wichtige funktion in meiner app verzichtet.

also jetzt nochmal, wie kann man am aller besten diesen code optimieren:

if (button1.Background.Equals(Colors.Yellow)) { ... }

es funktioniert ja auch:

if (button1.Visibility.Equals(Visibility.Visible)) { ... }

aber das brauche ich eigentlich nicht. außer ich würde noch weitere buttons einfügen, die außerhalb des displays liegen und keinerlei funktionalität haben und deren sichtbarkeit ich mit den drei anderen buttons ständig ändern würde. das wäre zwar eine simple alternative, aber ich glaube man kann es noch viel besser lösen.

Ich würd da eher dabei ansetzen was denn jetzt in den Buttons genau passiert. Ob eine Methode jetzt 50 oder 100 Befehle beinhaltet ist nämlich ziemlich egal, solange ja dann sowieso nur 20 davon ausgeführt werden, weil der Rest wegen der if/then/else Kette nicht ausgeführt wird.

Die Anzahl der Buttons ist auch eher für das Rendering relevant denn für die Performance der Ausführung des OnClick-Events (außer du baust da sehr viel am UI um). Generell ist zum Ausblenden sicher das Visibility-Attribut zu bevorzugen.

Insofern wäre es evtl. ganz interessant wenn du wirklich mal so wie Godscookie das oben geschrieben hat mit den DateTimes und Timespans mal herausfindest was denn in deinem Eventhandler so lange dauert.

ich habe den code mal bei einem event eingefügt, allerdings weiß ich nicht, wo ich die zeit nachschauen kann, die es braucht. habe die framerate counters entfernt, falls es dort irgendwo angezeigt werden sollte...

Nein, das musst du entweder nachher selbst ausgeben (z.B. mit einer MessageBox) oder aber du setzt dir in die Zeile danach einen Breakpoint und schaust dir im Watcher in VisualStudio an was da für ein Wert drinnen steht.

Wenn du keine Ahnung hast wovon ich mit Breakpoint und Watcher rede, dann empfehle ich sich dazu mal einzulesen, nachdem das fürs Debugging echt wichtig ist und dann um schnell auf ein Ergebnis zu kommen halt ein MessageBox.Show(neededTime.ToString());

Damit du dann wirklich rausfindest in welchem Teil du wieviel Zeit brauchst kannst du ja deinen Begin-Timestamp statt am Anfang der Methode halt dann in weiteren Tests erst später zu setzen.

Also dann z.B. statt:

Code:

---

DateTime startTime = DateTime.Now;
command1
command2
command3
DateTime endTime = DateTime.Now

---

das hier:

Code:

---

command1
DateTime startTime = DateTime.Now;
command2
command3
DateTime endTime = DateTime.Now

---

So findest du dann raus wo genau die Zeit verloren geht. Man könnte das auch mit weniger Umschreiberei mit dem Profiler des Windows Phone SDK machen - allerdings hab ich mich mit dem bisher noch nicht beschäftigt und ausgehend von den Profilern die ich kenne glaube ich, dass ich den wohl nicht auf die Schnelle übers Forum erklären könnte.

Zitat:

---

Zitat von StevieBallz

Nein, das musst du entweder nachher selbst ausgeben (z.B. mit einer MessageBox) oder aber du setzt dir in die Zeile danach einen Breakpoint und schaust dir im Watcher in VisualStudio an was da für ein Wert drinnen steht.

Wenn du keine Ahnung hast wovon ich mit Breakpoint und Watcher rede, dann empfehle ich sich dazu mal einzulesen, nachdem das fürs Debugging echt wichtig ist und dann um schnell auf ein Ergebnis zu kommen halt ein MessageBox.Show(neededTime.ToString());

Damit du dann wirklich rausfindest in welchem Teil du wieviel Zeit brauchst kannst du ja deinen Begin-Timestamp statt am Anfang der Methode halt dann in weiteren Tests erst später zu setzen.

Also dann z.B. statt:

Code:

---

DateTime startTime = DateTime.Now;
command1
command2
command3
DateTime endTime = DateTime.Now

---

das hier:

Code:

---

command1
DateTime startTime = DateTime.Now;
command2
command3
DateTime endTime = DateTime.Now

---

So findest du dann raus wo genau die Zeit verloren geht. Man könnte das auch mit weniger Umschreiberei mit dem Profiler des Windows Phone SDK machen - allerdings hab ich mich mit dem bisher noch nicht beschäftigt und ausgehend von den Profilern die ich kenne glaube ich, dass ich den wohl nicht auf die Schnelle übers Forum erklären könnte.

---

danke für die hilfreiche antwort, auch wenn es etwas spät ist! der code ist eigentlich echt nützlich, allerdings zeigt er bei mir zumindest oft unterschiedliche werte an. hatte letztens glaub ich c.a. 0,3 sekunden, was echt nicht so toll ist. wenn ich meinen code an einigen stellen verkürze wird die performance verbessert aber kleinigkeiten gibt es dann nicht mehr. ich glaub ich werde das mit den button visibilities umsetzen und den restlichen code etwas modifizieren und dann auch hinsichtlich der performance nichts mehr machen!