c++.de :: Performance von new vs Stack (war: Nekropost in Qt vs Boost)

X_2F9 Mitglied 16:54:21 01.08.2012 Titel:

Sorry wenn ich den Beitrag nach fast 2 Jahren raushole, aber ich weiß nicht ob sich das als extra Thema lohnt. Hab den Beitrag über Google gefunden weil ich mich auch gerade nach dem Sinn der Boost Bibliothek schlau mach.

@RHBaum, du meintest "new" ist der Laufzeitperformancekiller schlechthin. Das wusste ich bisher noch garnicht, und hab mal etwas danach gegooglt, jedoch nichts gefunden. Hast du hierfür Quellen oder Vergleiche?

Ciao..

SeppJ Moderator 17:01:22 01.08.2012 Titel:

X_2F9 schrieb:

Sorry wenn ich den Beitrag nach fast 2 Jahren raushole, aber ich weiß nicht ob sich das als extra Thema lohnt. Hab den Beitrag über Google gefunden weil ich mich auch gerade nach dem Sinn der Boost Bibliothek schlau mach.

Wenn du weder etwas zu sagen hast, noch eine Frage (zum Thema!) hast, warum holst du dann so olle Kamellen hoch? Lass das bitte.

Zitat:

@RHBaum, du meintest "new" ist der Laufzeitperformancekiller schlechthin. Das wusste ich bisher noch garnicht, und hab mal etwas danach gegooglt, jedoch nichts gefunden. Hast du hierfür Quellen oder Vergleiche?

Das wird in C++ als Allgemeinwissen angesehen. Ein new kostet dich ein paar hundert Prozessortakte für das new alleine, ein automatisches Objekt kostet so zwischen 0 und 1 Takt, je nachdem, wie man die Kosten genau definiert. Außerdem sind sie wesentlich besser optimierbar für den Compiler.

Quellen? Jeder Java vs. C++ Benchmark, wobei verschiedene Benchmarks oftmals unterschiedliche Betonungen haben. Pro-C++ Benchmarks haben dann Algorithmen in denen vielen Variablen erzeugt und abgeräumt werden müssen und viel auf Datenfelder zugegriffen wird und C++ gewinnt haushoch, Pro-Java Benchmarks vermeiden diese Schwächen und kommen dann mitunter sogar zu einem ungefährem Unentschieden.

Zur Not schreib dir selber flott etwas, einmal machst du alle Variablen mit new, einmal alle automatisch und dann vergleichst du mal. Dabei möglichst wenig rechnen, damit du nicht die Rechnung selber misst, sondern das new vs automatische Variablen.

Skym0sh0 Mitglied 17:05:06 01.08.2012 Titel:

ich habe mir früher immer gedacht, dass stackobjekte immer im prozessorspeicher erstellt werden (also mehr als sauschnell) und heapsachen im arbeitsspeicher, was ja erheblich langsamer ist schon per definition.

aber die aussage so ist falsch und maximal als sinnfreie erklärung im hinterkopf zu halten

Bashar Mitglied 17:05:44 01.08.2012 Titel:

new/delete muss Speicher vom Heap besorgen. Das bedeutet in einer komplexen Datenstruktur einigen Zeigern nachjagen, um einen Speicherblock zu besorgen und zurechtzuschneiden, und ihn am Ende wieder freigeben und ggf. mit benachbarten freien Blöcken verschmelzen. Falls kein freier Block existiert, muss beim Betriebssystem mehr Speicher angefordert werden.
Eine Stackallokation ist eine Subtraktion der Objektgröße vom Stackpointer und damit praktisch kostenlos.

X_2F9 Mitglied 17:06:20 01.08.2012 Titel:

Ok, tut mir leid.

Ein bisschen Allgemeinwissen (dachte ich) hab ich bereits. Hab mir das C++ Buch "Einführung in die Programmierung mit C++" angesehen, was ja relativ neu ist. Bisher wusste ich das mit new jedoch nicht. Gibt es eine "Sammlung" solcher Anfängertipps? Gibt ja sicher noch mehr 'fallen' in die ich treten werde.

Danke auf jedenfall für die Erklärung!

Skym0sh0 Mitglied 17:08:21 01.08.2012 Titel:

die bücher von scott meyers effektive c++ und more effective c++ (obwohl das zweite mittlerweile echt veraltet ist und auch teilweise in den neuen auflagen des ersten teils eingegangen ist)

X_2F9 Mitglied 17:19:42 01.08.2012 Titel:

@SeppJ, ich glaub das schon das new langsamer ist. Hab nur nach dem "warum" gesucht, weil ich im Internet nichts gefunden habe. Ich dachte zwischen Objektinitialisierung gäb es keinen Unterschied.

Werd mir wohl mal das aktuelle Buch von Scott Mayers zulegen

http://www.amazon.de/Effe ....... qid=1343833820&sr=1-2

Skym0sh0 Mitglied 17:27:54 01.08.2012 Titel:

sehr gut

Unregistrierter

Zusätzlich zu der Tatsache, dass new erst suchen muss, kann es in nebenläufigen Anwendungen passieren, dass sich die einzelnen Threads gegenseitig im Weg stehen. Man kann das zwar verhindern, indem man jedem Thread einen eigenen Heap unterjubelt (mehr dazu hier), aber das ist keine ganz schmerzfreie Angelegenheit -- insbesondere, wenn ein Thread in die Lage kommt, Daten aufräumen zu müssen, die ein anderer angefordert hat, was bei geteilten Containern schon mal vorkommen kann.

Auch darf davon ausgegangen werden, dass die Spitze des Stacks bereits im Cache liegt; das dürfte aber nur bei sehr kleinen und extrem kurzlebigen Objekten von größerer Bedeutung sein. Spannend ist allerdings, dass Objekte, die im selben Zusammenhang angelegt wurden, dann direkt nebeneinander (also cachefreundlich) im Speicher liegen, wenn sie alle auf den Stack gelegt wurden. Kommt man nach längerer Arbeit noch mal auf sie zurück, muss man so nicht für jedes Mini-Objekt einzeln zum Hauptspeicher rausstiefeln.

yihaaa Mitglied 21:14:58 01.08.2012 Titel:

Ich habe genau das Buch auch gelesen, es wird sehr viel mit new und delete gemacht, aber ich glaube es wird nicht gesagt, warum new langsamer ist. Man weiß das es langsamer ist, aber es wird dort nicht explizit erklärt. Jedoch ist das Buch alles in allem sehr Empfehlenswert.

MfG