spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Passiert dir das nie, dass du dich bei gewissen grundlegenden Dingen, die du ständig machst, manchmal fragst, welche von all den verschiedenen Möglichkeiten das Gleiche zu tun nun eigentlich die effizienteste ist!?

Doch, aus reiner Neugier schon. Nur für die Praxis meist total irrelevant.

Zitat von »BlueCobold«

Zitat von »dot«

Passiert dir das nie, dass du dich bei gewissen grundlegenden Dingen, die du ständig machst, manchmal fragst, welche von all den verschiedenen Möglichkeiten das Gleiche zu tun nun eigentlich die effizienteste ist!?

Doch, aus reiner Neugier schon. Nur für die Praxis meist total irrelevant.

Na eben; für die Praxis meiner Erfahrung nach genau so lange irrelevant, bis es dann plötzlich doch einmal relevant ist...

Daher: in Funktion auslagern. Funktion ueberall aufrufen. Wenns relevant wird, diese Funktion optimieren sonst weiter am Projekt bauen.

So ist es. Und das wird's nie werden, schätze ich

Das Problem ist halt, dass es in der Regel nicht so einfach ist. Wenn der Code nicht zumindest bereits mit entsprechenden Optimierungen im Hinterkopf geschrieben wurde, kann man diese nicht später einfach mal so draufklatschen, da beispielsweise der Datenfluss im Programm plötzlich völlig anders sein müsste. Der Glaube, Performance und Design als völlig unabhängig voneinander betrachten zu können, ist – zumindest meiner Erfahrung nach – ziemlich naiv. Selbst in einem simplen Fall wie dem konkreten Beispiel hier: Natürlich macht es Sinn, das Einfügen in eine Funktion zu packen, aber, wie wir gesehen haben, musst du dabei bereits wissen, wie genau du die Signatur der Funktion wählst, da wichtige Optimierungen ansonsten nichtmehr funktionieren...

Klar, Performance hängt meist mehr an der verwendeten Datenstruktur, dem Datenfluss und dem verwendeten Algorithmus als an solchem Kinderkram. Aber genau das ist es, weswegen ich das als premature optimization bezeichnet habe.

Seine Frage zielte aber so wie ich es verstanden habe auch eher auf eine eventuelle Optimierung durch den Compiler ab als jetzt selbst eine zu implementieren. Ob dem jetzt so ist kann ich nicht sagen, und ob es Regeln für das Verlassen des Blocks wie im ersten Fall gib Weiß ich leider so spontan auch nicht.

Vorstellen könnte ich mir im ersten Fall jedoch, dass der Compiler eine Optimierung ähnlich wie im return Fall move Semantik anstatt copy Semantik einsetzen könnte, da ja das blockende und somit der Gültigkeitsbereich der in den Vektor zu befördernden Struktur verlassen wird. Aber wie gesagt ob das jetzt gemacht wird, oder überhaupt dem Compiler erlaubt ist kann ich nicht sagen.

Das resize() in jedem Schleifendurchlauf ist jedenfalls erstmal die gröbste Performance-Bremse, die der OP rausbauen sollte. Solange es an solchen grundlegenden Missverständnissen hängt, glaube ich nicht, dass irgendwas von der Diskussion rund um move() oder emplace_back() irgendwie relevant ist.

Natürlich ist es sinnvoller, das resize(), wenn möglich (immerhin muss man dazu die Größe vorher kennen, was nicht notwendigerweise der Fall ist), nicht in der Schleife zu machen, aber, wie gesagt, würde ich den relativen Overhead des resize() nicht überbewerten, da das die meiste Zeit auf nicht mehr als ein if und eine Addition rauslaufen wird, was unter Umständen im Vergleich zu sinnlosen Kopien am Ende dann nicht viel ausmacht...

Zitat von »Schrompf«

Das resize() in jedem Schleifendurchlauf ist jedenfalls erstmal die gröbste Performance-Bremse, die der OP rausbauen sollte. Solange es an solchen grundlegenden Missverständnissen hängt, glaube ich nicht, dass irgendwas von der Diskussion rund um move() oder emplace_back() irgendwie relevant ist.

resize(size()+1) macht genau das gleiche wie push_back(Element());

So wie ich das sehe ist das so Absicht und kein Missverstaendnis.