Performace Funktion

laraM

Angenommen ich habe die Klasse Auto:

class Auto{

public:
    blubb
    void kaputt(int a, int b) //gleich dazu mehr

private:
    vector<Rad> AutoRad(4);
}

die Funktion kaputt soll jetzt berechnen, ob Rad Nr. a und Rad Nr. b kaputt sind.

Sollte man hier vielleicht auch mit Referenzen arbeiten, also:

void kaputt(int& a, int& b)

oder ist es sinnvoller die Funktion so aufzurufen:

void kaputt(Rad &RadA, Rad RadB&)

Das Beispiel hab ich mir jetzt irgendwie ausgedacht, damit ich meine Frage formulieren kann, es soll jetzt nicht sinnvoll in sich sein.

Ich würde gerne wissen, welche Funktion die beste Performance hat.
Ob es sich lohnt &int anstatt int aufzurufen, oder aber besser gleich die Referenz auf das Objekt mit welchem man irgendwas berechnet.

Skym0sh0

also kommst drauf an was du in der funktion machst
die standart typen (int, char, double...) lohnen sich nicht per referenzenzu übergeben

aber eigene typen eigendlich schon, aber im normalfall werden die als const & übergeben, weil was passiert hier:

void foo(std::string & s)
{
    //mach was
}

int main()
{
    std::string s1 = "test";
    foo(s1);
    foo("test");
}

beim zweiten könnte der compiler dir ne fehlermeldung annen kopf schmeissen oder dir schmierts programm ab

Nexus

Skym0sh0, ich glaube, du hast das Thema ein wenig verfehlt.

Kommt auch drauf an, wie du von aussen Zugriff auf die Räder hast. Denn je nachdem kannst du gar keine Räder direkt übergeben.

Welche Funktionalität ist dir lieber? Zahlen sind grundsätzlich sicherer, da auch Räder von anderen Autos übergeben werden können, während bei den Indizes eine einfache Bereichsprüfung reicht. Zudem würde die Abfrage auf Räder wahrscheinlich auf sowas hinauslaufen:

Auto MeinFiat;
bool DrittesRadKapput = MeinFiat.kapput(MeinFiat.getRad(3));

Da kannst du gleich auf die Nummern prüfen. Aber eben, je nach Kontext ist das halt unterschiedlich...

pumuckl

laraM schrieb:

Ich würde gerne wissen, welche Funktion die beste Performance hat.

Das hängt von verschiedensten Faktoren ab, meist kann man das so pauschal nicht sagen, es sei denn du baust in einer der Funktionen einen dicken Schnitzer ein. Davon mal abgesehen lohnt sich für die Performanceeinbußen nicht, sich darüber Gedanken zu machen. In den Meisten Fällen wo hier im Forum nach Performance gefragt wird hat der Fragesteller schon durch Eröffnen des Posts mehr Lebenszeit verloren als er durch Optimierungen an der jeweiligen Funtkion je wieder wettmachen kann.

Generelle Richtlinie zum Vorgehen für gute und schnelle Programme:

- Entwerfe ein gut zu wartendes Programm mit ordentlichem Design.
- Denke dabei nicht an Performance sondern an verständliches, erweiterbares, wiederverwendbares und leicht wartbares Design.
- Implementiere deine Funktionen klar gegliedert mit sinnvollen Algorithmen.
- Denke dabei nicht an Performance sondern an lesbaren und verständlichen Code.
- Teste dein fertiges Programm gründlich auf Bugs und behebe diese
- Denke dabei nicht an Performance, es sei denn du stellst fest dass es irgendwo doch recht lang dauert.
- Wenn du jetzt tatsächlich festgestellt hast dass es ein Performanceproblem gibt, dann benutze einen Profiler um das Problem zu lokalisieren.
- Erst jetzt lohnt es sich, sich Gedanken über die Performance einzelner Implementierungen zu machen.

Oder um ein bekanntes Zitat zu bringen:

Donald Knuth schrieb:

Premature optimization is the root of all evil

asc

pumuckl schrieb:

...

Diese Zusammenstellung ist so gut das sie IMHO in die FAQ gehört

volkard

asc schrieb:

pumuckl schrieb:

...

Diese Zusammenstellung ist so gut das sie IMHO in die FAQ gehört

kommt nicht in die FAQ, weil zu dogmatisch und falsch.

richtig ist:
denke während der gesamten entwicklung auch an performance, oder es kommt blöder mist raus.

kimmi

Da gibt es auch einen recht guten Artikel drüber. Keinaussage: Denke bei der Wahl der Algorithmen immer auch an den Einsatz dieser und die daruse resultierende Performance, sonst können am Ende ziemlich üble Überraschungen auftauchen ( was ich schon mehrmals in verschiedenen Projekten festellen musste ). Vielleicht kennt jemand ja den Link, ich hab den leider verloren.

Gruß Kimmi

pumuckl

kimmi schrieb:

Keinaussage: Denke bei der Wahl der Algorithmen immer auch an den Einsatz dieser und die daruse resultierende Performance,

Das ist das, was ich mit "sinnvollen Algorithmen" sagen wollte. Natürlich soll das "denk dabei nicht an die Performance" nicht bedeuten, dass man seinen gesunden Menschneverstand ausschalten sollte.
Ich versuchs also nochmal umzuformulieren:

- Designe dein Programm so, dass es zwar möglichst schlank ist, aber nicht auf Kosten der Wartbarkeit, Verständlichkeit und Übersichtlichkeit. Das heißt: Du solltest nicht nur aus Performanceängsten auf zusätzliche Abstraktionen, Indirektionen und ähnliches verzichten.
- Finde für deine Funktionen möglichst schnelle Algorithmen, aber implementiere sie dennoch verständlich und nachvollziehbar. Das heißt: versuche nicht, nur aus Performancegründen alles unter Verwendung von Pointerarithmetik, trickreichem Einsatz von Bitmanipulationen und der kleveren Ausnutzung von Kurzschlussoperatoren in einen Ausdruck zu quetschen.
- Kenne die üblichen Verdächtigen für schnelleren Code (z.B. ++iter vs. iter++), sei aber bereit darauf zu verzichten wenn es sein muss. Einige brechen sich einen ab um eine Zeile "optimalen" Code zu erzeugen und erzeugen dafür 10 Zeilen schlimmeren Code der zudem noch schlechter lesbar (und damit schlechter wartbar und debugbar) ist.
- Halte dich nicht mit Kleinigkeiten auf, nur weil du glaubst du könntest die Performance in einer einzelnen Zeile Code verbessern. Eine einzelne eventuell unnötige Objektkopie fällt nicht groß ins Gewicht oder wird sogar ganz weg optimiert.

Grundsätzlich gilt, den Aufwand einer "Optimierung" gegen den Gewinn abzuschätzen, wobei der Aufwand nicht nur das Entwerfen und Tippen des Codes umfasst sondern auch die Zeit die man damit verbringt sich beim Debuggen und durchlesen verständlich zu machen, was da eigentlich vor sich geht.

volkard

jup. und dem würde ich noch hinzufügen:

- der einfachere code tendiert normalerweise dahin, am ende doch der schnellere code zu sein, denn die *fetten* optimierungen kann man nur finden, wenn das prog toll übersichtlich ist, und nur einbauen, wenn es gut wartbar ist.

- man sollte sich mit mit laufzeitabschätzungen beschäftigen und wenn man auf kosten der wartbarkeit aus einem O(n^2) ein O(n) macht oder aus O(n) ein O(log(n)), dann geht das meistens schon ok. erstetzt man aber ein O(1) durch ein schnelleres O(1), ist das allermeistens grober unfug.