Performance mit/ohne if-Anweisung

  • Performance mit/ohne if-Anweisung

    Liebe Community,

    ich habe eine Frage zur Performance. Ich bin mir sicher, dass es sich hier um einen Zeitunterschied von wenigen Millisekunden handelt, aber bei viel Code kann das dann schon mal einen kleinen Unterschied ausmachen.

    Jedes mal wenn ich eine Methode aufrufe, möchte ich einen Button aktivieren. Soll ich vorher abfragen, ob der Button deaktiviert ist und erst dann aktivieren, oder einfach immer aktivieren, auch wenn der Button bereits aktiviert ist?

    Was ist hier der schönere Code und welcher wird (theoretisch) schneller ausgeführt?

    Mit freundlichen Grüßen

    TheFuriousLion

  • Also überlege mal systematisch:

    Quellcode

    1. if(![button istAktiviert])
    2. [button aktiviere];

    vs.

    Quellcode

    1. [button aktiviere];

    Jetzt wird der Programmierer der Methode 'aktiviere' hofentlich folgendes gemacht haben:

    Quellcode

    1. - (void) aktiviere
    2. {
    3. if(istAktiviert)
    4. return;
    5. ... viel Arbeit ...
    6. }


    Wenn Du Performance optimieren willst, spielt es eine Rolle, was wie lange dauert.
    Es gilt (grob)
    * ein if ist sehr schnell
    * ein C-Statement auch
    * ein Methodenaufruf ist langsamer

    Also bedeutet der if einen kaum meßbaren Unterschied. Aber die Abfrage ob der Button bereits aktiviert ist, ist ein zweiter Methodenaufruf. Also wird es durch den if() sogar langsamer. D.h. diese Optimierung hat den gegenteiligen Effekt.

    Nur was heiß hier schnell und langsam?

    Du kannst davon ausgehen dass ein if-Befehl unter 10 Nanosekunden dauert. Und ein Methodenaufruf auch noch um Sub-Mikrosekundenbereich liegt (außer der Code muß erst von externem Speicher geladen werden).

    D.h. das ... viel Arbeit ... ist sowieso das Langsamste von allem.

    Daher kommt es dass es müßig ist sich an dieser Stelle Gedanken zur Performance zu machen. Da würde ich also weniger die Laufzeit des Programms optimieren, sondern die Programmierer-Zeit. D.h. weglassen spart dem Programmierer ein paar Sekunden.

    -- hns

  • hns schrieb:

    Also überlege mal systematisch:

    Quellcode

    1. if(![button istAktiviert])
    2. [button aktiviere];

    vs.

    Quellcode

    1. [button aktiviere];

    Jetzt wird der Programmierer der Methode 'aktiviere' hofentlich folgendes gemacht haben:

    Quellcode

    1. - (void) aktiviere
    2. {
    3. if(istAktiviert)
    4. return;
    5. ... viel Arbeit ...
    6. }


    Wenn Du Performance optimieren willst, spielt es eine Rolle, was wie lange dauert.
    Es gilt (grob)
    * ein if ist sehr schnell
    * ein C-Statement auch
    * ein Methodenaufruf ist langsamer

    Also bedeutet der if einen kaum meßbaren Unterschied. Aber die Abfrage ob der Button bereits aktiviert ist, ist ein zweiter Methodenaufruf. Also wird es durch den if() sogar langsamer. D.h. diese Optimierung hat den gegenteiligen Effekt.

    Nur was heiß hier schnell und langsam?

    Du kannst davon ausgehen dass ein if-Befehl unter 10 Nanosekunden dauert. Und ein Methodenaufruf auch noch um Sub-Mikrosekundenbereich liegt (außer der Code muß erst von externem Speicher geladen werden).

    D.h. das ... viel Arbeit ... ist sowieso das Langsamste von allem.

    Daher kommt es dass es müßig ist sich an dieser Stelle Gedanken zur Performance zu machen. Da würde ich also weniger die Laufzeit des Programms optimieren, sondern die Programmierer-Zeit. D.h. weglassen spart dem Programmierer ein paar Sekunden.

    -- hns


    genau. eine rolle spielt aber die verständlichkeit des codes also ist es oft/meist besser einen verständlichen einzeiler zu verwenden anstatt 10 zeilen code der um den faktor x schneller ist (vor allem wenn der einzeiler auch schon sehr schnell ist und der code manuell (also vom benutzer der app ausgelöst wird) und nicht extrem oft per code (eventuell sogar rekursiv) aufgerufen wird.

    optimieren sollte man erst wenn man merkt dass etwas (zu) langsam ist.

  • zerm, das hat damit nichts zu tun. Einerseits will ich, dass meine Programme auch auf älteren Macs flüssig laufen, d. h. möchte ich mir von Anfang an Gedanken um Performance machen. Andererseits will ich es einfach richtig machen.

    macmoonshine und hns, ich kann also davon ausgehen, dass sich die Programmierer der Standardmethoden schon Gedanken um diese Art von Problemen gemacht haben, oder?

  • TheFuriousLion schrieb:

    Andererseits will ich es einfach richtig machen.


    Dann, beachte die goldene Regel:

    Donald E. Knuth schrieb:

    There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.