Was ist schneller: Stack-Allokation oder Heap-Zuweisung

Stack-Allokation ist viel schneller, weil alles, was es wirklich tut, ist, bewegen Sie den stack-pointer.
Mit Speicher-pools, die Sie bekommen können eine vergleichbare Leistung aus dem heap, aber das kommt mit einer geringen Komplexität und seine eigenen Kopfschmerzen.

Auch, stack vs. heap ist nicht nur ein performance-Aspekt; darüber hinaus erfahren Sie eine Menge über die erwartete Lebensdauer der Objekte.

InformationsquelleAutor Torbjörn Gyllebring

Ehrlich gesagt, es ist trivial, ein Programm zu schreiben vergleichen Sie die Leistung:

#include <ctime>
#include <iostream>

namespace {
    class empty { }; //even empty classes take up 1 byte of space, minimum
}

int main()
{
    std::clock_t start = std::clock();
    for (int i = 0; i < 100000; ++i)
        empty e;
    std::clock_t duration = std::clock() - start;
    std::cout << "stack allocation took " << duration << " clock ticks\n";
    start = std::clock();
    for (int i = 0; i < 100000; ++i) {
        empty* e = new empty;
        delete e;
    };
    duration = std::clock() - start;
    std::cout << "heap allocation took " << duration << " clock ticks\n";
}

Es wird gesagt, dass ein törichter Konsistenz ist der Kobold der kleinen Geister. Offenbar Optimierung Compiler sind die hobgoblins von vielen Programmierer-Köpfen. Diese Diskussion genutzt werden, unten die Antwort, aber die Leute anscheinend nicht die Mühe gemacht, zu Lesen, dass weit, so ziehe ich es bis hier, zu vermeiden, immer Fragen die ich schon beantwortet.

Ein optimierender compiler feststellen, dass dieser code tut nichts, und optimieren Sie alle Weg. Es ist der optimizer die Arbeit zu tun Sachen wie, dass, und die Bekämpfung der optimizer ist ein Narr Botengang.

Ich würde empfehlen, kompilieren Sie den code mit Optimierung ausgeschaltet, weil es keine gute Weise, zu täuschen, die jeden Optimierer, die derzeit in Gebrauch oder den Gebrauch in der Zukunft.

Wer schaltet den Optimierer an und meckert dann über den Kampf sollte es werden, das Gegenstand der öffentlichen Lächerlichkeit preisgegeben.

Wenn ich kümmerte Nanosekunden-Präzision würde ich nicht verwenden std::clock(). Wenn ich wollte, die Veröffentlichung der Ergebnisse als Doktorarbeit würde ich eine größere Sache über dieses, und ich würde wahrscheinlich zu vergleichen, GCC, Tendra/Ten15, LLVM, Watcom, Borland, Visual C++, Digital Mars, ICC und andere Compiler. Wie es ist, heap-Zuweisung dauert hundert mal länger als stack-Zuweisung, und ich sehe nichts nützliches über die Untersuchung der Frage nicht weiter.

Der Optimierer hat eine mission, um loszuwerden, der code, den ich Teste. Ich sehe keinen Grund dafür, zu sagen, dass der Optimierer ausführen und dann versuchen zu täuschen, die der Optimierer in eigentlich nicht optimieren. Aber wenn ich sah, mit dem Wert zu tun, die ich tun würde, eine oder mehrere der folgenden:

1. Hinzufügen eines Daten-Mitglieds auf empty, und auf die Daten zugreifen, Mitglied in der Schleife, aber wenn ich immer nur Lesen von Daten, die Mitglied der optimizer tun können, constant folding und entfernen Sie die Schleife, wenn ich immer nur schreiben, um die Daten-member, kann der Optimierer überspringen Sie alle, aber die Letzte iteration der Schleife. Außerdem, die Frage war nicht "stack Allokation und data access vs. heap und den Zugriff auf Daten."

2. Erklären e volatile, aber volatile wird oft falsch zusammengestellt (PDF).

3. Nehmen Sie sich die Adresse von e innerhalb der Schleife (und vielleicht weisen Sie auf eine variable, die deklariert extern und in einer anderen Datei definiert). Aber selbst in diesem Fall kann der compiler feststellen, dass -- auf dem Stapel mindestens -- e wird immer zugewiesen wird, den gleichen Speicher-Adresse, und führen Sie dann das constant folding wie in (1) oben. Ich bekomme alle Iterationen der Schleife, aber das Objekt ist eigentlich nie vergeben.

Neben dem offensichtlichen, ist dieser test fehlerhaft, dass es Maßnahmen Zuweisung und-Freigabe, und die ursprüngliche Frage gar nicht zu Fragen, über die Freigabe. Natürlich Variablen auf dem Stapel reserviert werden automatisch freigegeben, am Ende Ihrer Reichweite, also ruft nicht delete würde (1) verzerren die zahlen (Stapel-Freigabe ist im Lieferumfang enthalten in den zahlen über die stack-Zuweisung, so ist es nur fair zu Messen heap deallocation) und (2) bewirken ein ziemlich schlechtes Gedächtnis Auslaufen, es sei denn, wir halten eine Referenz auf das neue Zeiger und rufen delete nach wir haben unsere Zeit-Messung.

Auf meinem Rechner mit g++ 3.4.4 auf Windows, bekomme ich "0 Zeiteinheiten" für beide stack-und heap-Zuweisung für etwas weniger als 100000 Zuweisungen und selbst dann bekomme ich "0 Zeiteinheiten" für stack-Allokation und die "15-Uhr-ticks" für heap-allocation. Wenn ich Messen 10,000,000 Zuweisungen, stack Allokation dauert 31 Uhr tickt und heap-Zuweisung dauert 1562 Uhr tickt.

Ja, ein optimierender compiler kann elide erstellen der leeren Objekten. Wenn ich das richtig verstehe, kann es auch umgehen, aber die ganze erste Schleife. Wenn ich bis stieß der Iterationen, die bis zu 10.000.000 stack Allokation nahmen 31 Uhr tickt und heap nahm 1562 Uhr tickt. Ich denke, es ist sicher zu sagen, dass ohne Rücksprache mit g++ zu optimieren, die ausführbare Datei g++ nicht umgehen, aber die Konstruktoren.

In den Jahren, seit ich dies schrieb, ist die Einstellung auf Stack Overflow wurde, um post-performance von optimierten builds. Im Allgemeinen, ich denke, das ist richtig. Aber ich denke immer noch, es ist dumm zu Fragen, der compiler optimiert code, wenn Sie in der Tat nicht wollen, dass die code optimiert. Es scheint mir sehr ähnlich zu zahlen extra für valet-Parkplatz, aber die Verweigerung der hand über die Tasten. In diesem speziellen Fall, will ich nicht den optimizer laufen.

Verwenden eine leicht modifizierte version von der benchmark (um die Adresse der gültigen Punkt, dass das ursprüngliche Programm nicht zuweisen, die etwas auf den stack jedes mal durch die Schleife) und kompilieren ohne Optimierungen, aber die Verknüpfung zur Freigabe von Bibliotheken (Adresse die gültigen Punkt, dass wir nicht wollen, auch eine Verlangsamung verursacht durch die Verknüpfung der debug-Bibliotheken):

#include <cstdio>
#include <chrono>

namespace {
    void on_stack()
    {
        int i;
    }

    void on_heap()
    {
        int* i = new int;
        delete i;
    }
}

int main()
{
    auto begin = std::chrono::system_clock::now();
    for (int i = 0; i < 1000000000; ++i)
        on_stack();
    auto end = std::chrono::system_clock::now();

    std::printf("on_stack took %f seconds\n", std::chrono::duration<double>(end - begin).count());

    begin = std::chrono::system_clock::now();
    for (int i = 0; i < 1000000000; ++i)
        on_heap();
    end = std::chrono::system_clock::now();

    std::printf("on_heap took %f seconds\n", std::chrono::duration<double>(end - begin).count());
    return 0;
}

zeigt:

on_stack took 2.070003 seconds
on_heap took 57.980081 seconds

auf meinem system beim kompilieren mit der Befehlszeile cl foo.cc /Od /MT /EHsc.

Können Sie nicht einverstanden mit meinem Ansatz zu einem nicht-optimierten bauen. Das ist in Ordnung: fühlen Sie sich frei ändern Sie den Maßstab so viel wie Sie wollen. Wenn ich auf Optimierung, bekomme ich:

on_stack took 0.000000 seconds
on_heap took 51.608723 seconds

Nicht, weil stack-Allokation ist eigentlich augenblicklich, sondern weil jede halbwegs anständige compiler feststellen können, dass on_stack nichts nützliches und optimiert werden kann entfernt. GCC auf meinem Linux-laptop auch bemerkt, dass on_heap nichts nützliches, und optimiert es Weg, wie gut:

on_stack took 0.000003 seconds
on_heap took 0.000002 seconds

InformationsquelleAutor

Schreiben Sie einen speziellen heap-Zuweisung für bestimmte Größen von Objekten, die sehr performant arbeitet. Jedoch, die Allgemeinen heap-allocator ist nicht besonders performant.

Ich Stimme mit Torbjörn Gyllebring über die erwartete Lebensdauer der Objekte. Guter Punkt!

InformationsquelleAutor Chris Jester-Young

In der Regel stapelzuweisung nur aus der Subtraktion von der stack-pointer-register. Dies ist Tonnen schneller als die Suche in einem heap.

Manchmal stack Allokation erfordert das hinzufügen einer Seite(s) des virtuellen Speichers. Hinzufügen einer neuen Seite eingeschossen Speicher nicht benötigen, Lesen Sie eine Seite von der Festplatte, so dass in der Regel dies ist immer noch Tonnen schneller als die Suche in einem heap (vor allem, wenn ein Teil des heap wurde ausgelagert zu haben). In einer seltenen situation, und Sie bauen könnten, so ein Beispiel, genug Platz nur gerade zufällig zur Verfügung steht, die in einem Teil der heap, die bereits im RAM sind, aber die Zuweisung einer neuen Seite, für die der stack hat, warten Sie, bis die andere Seite auf die Festplatte geschrieben. In dieser seltenen situation, wird der heap schneller.

InformationsquelleAutor Windows programmer

Einem Stapel hat eine begrenzte Kapazität, während ein heap ist nicht. Die typischen stack für einen Prozess oder thread ist um 8K. Sie können nicht ändern die Größe, wenn es einmal zugeordnet.

Eine stack-variable folgt die scoping-Regeln, während ein Haufen nicht. Wenn Ihr instruction pointer geht über eine Funktion, alle neuen Variablen im Zusammenhang mit der Funktion Weg.

Wichtigsten von allen, können Sie nicht Vorhersagen, die die gesamte Funktion aufrufen, Kette im Voraus. Also nur etwa 200 bytes Zuteilung auf Ihren Teil auslösen kann, ist ein stack-überlauf. Dies ist besonders wichtig, wenn Sie schreiben eine Bibliothek, nicht eine Anwendung.

InformationsquelleAutor yogman

Wohl das größte problem der heap vs. stack-Allokation ist, dass heap im Allgemeinen Fall ist ein unbounded Betrieb, und so können Sie es nicht verwenden, wo timing ist ein Problem.

Für andere Anwendungen wo timing ist nicht ein Problem, es mag nicht wie viel, aber wenn man heap wählen viel, wird sich dies auf die Ausführungsgeschwindigkeit. Immer versuchen, den Stapel von kurzer Dauer und oft den allokierten Speicher (z.B. in Schleifen), und so lange wie möglich tun heap-Zuweisung während des Starts der Anwendung.

InformationsquelleAutor larsivi

Stack Allokation wird fast immer als schnell oder schneller als heap-Zuweisung, obwohl es sicherlich möglich, einen heap-Zuweisung verwenden Sie einfach einen stack-basierten Allokation Technik.

Jedoch, gibt es größere Probleme beim Umgang mit der performance-stack vs. heap-basierten Zuteilung (oder in etwas bessere Bedingungen, lokale oder externe Vergabe). In der Regel, heap (extern) Zuweisung ist langsam, weil es ist der Umgang mit vielen verschiedenen Arten von Zuweisungen und-Allokation-Muster. Eine Reduzierung des Umfangs der Zuweisung, die Sie verwenden (so dass es lokal auf dem Algorithmus/code) dazu neigen wird, um die Leistung zu erhöhen ohne wesentliche Veränderungen. Hinzufügen bessere Struktur, Ihre Aufteilung Muster, zum Beispiel, zwingt eine LIFO-Bestellung über die Zuteilung und Freigabe-Paare können auch verbessern Sie Ihre allocator performance durch die Verwendung der Zuweisung in einfacher und strukturierter Weise. Oder Sie verwenden können, oder schreiben Sie eine Zuweisung abgestimmt, für Ihre jeweilige Zuweisung Muster; die meisten Programme weisen ein paar diskrete Größen Häufig, so dass ein heap basiert auf einem lookaside buffer von ein paar Feste (möglichst bekannten) Größen führen sehr gut. Windows verwendet die low-fragmentation-heap genau aus diesem Grund.

Auf der anderen Seite, stack-basierte Allokation auf einem 32-bit-Speicherbereich ist auch voller Gefahren, wenn Sie zu viele threads. Die Stapel müssen einen zusammenhängenden Speicherbereich, so dass die mehr threads du hast, desto mehr virtuelle Adresse Speicherplatz Sie benötigen, für Sie zu laufen ohne einen stack-überlauf. Dies wird nicht ein problem sein (für jetzt) mit 64-bit, aber es kann sicherlich verheerenden Schaden anrichten in lange Laufenden Programme mit vielen threads. Der virtuelle Adressraum aufgrund der Fragmentierung ist immer ein Schmerz zu behandeln.

InformationsquelleAutor MSN

Gibt es eine Allgemeine Aussage darüber getroffen werden, solche Optimierungen.

Die Optimierung, die Sie bekommen, ist proportional zur Menge der Zeit, die das Programm counter ist eigentlich im code.

Wenn Sie sample program counter, finden Sie heraus, wo er verbringt seine Zeit, und das ist in der Regel in einem kleinen Teil des Codes, und oft in der Bibliothek Routinen, die Sie haben keine Kontrolle über.

Nur, wenn Sie es finden, verbrachte viel Zeit in der heap-Allokation und Ihrer Objekte wird es merklich schneller, Stapel-zuordnen.

InformationsquelleAutor Mike Dunlavey

class Foo {
public:
    Foo(int a) {

    }
}
int func() {
    int a1, a2;
    std::cin >> a1;
    std::cin >> a2;

    Foo f1(a1);
    __asm push a1;
    __asm lea ecx, [this];
    __asm call Foo::Foo(int);

    Foo* f2 = new Foo(a2);
    __asm push sizeof(Foo);
    __asm call operator new;//there's a lot instruction here(depends on system)
    __asm push a2;
    __asm call Foo::Foo(int);

    delete f2;
}

Wäre es, wie dies in asm. Wenn Sie in func, die f1 und Zeiger f2 zugewiesen wurde, wurde auf den stack (automatische Speicherung). Und durch die Art und Weise, Foo f1(a1) hat keine Anweisung Auswirkungen auf stack-pointer (esp),Es hat gewesen zugeteilt, wenn func will das Mitglied f1 es die Anweisung ist so etwas wie dieses: lea ecx [ebp+f1], call Foo::SomeFunc(). Eine andere Sache, die stack-Zuweisung machen kann jemand denken, das Gedächtnis ist so etwas wie FIFO, die FIFO nur geschehen, wenn Sie gehen in eine Funktion, wenn Sie sind in der Funktion und weisen so etwas wie int i = 0 gibt es keine push passiert ist.

InformationsquelleAutor bitnick

Im Allgemeinen, stack-Allokation ist schneller als heap-Zuweisung wie bereits erwähnt bei fast jeder Antwort oben. Ein stack, push und pop O(1), in der Erwägung, dass die Zuweisung oder Befreiung aus einem heap kann verlangen, einen Spaziergang von früheren Zuteilungen. Allerdings sollten Sie nicht in der Regel die Zuweisung in engen, performance-intensiven Schleifen, so dass die Wahl wird in der Regel nach unten kommen, um andere Faktoren.

Könnte es gut sein, um diese Unterscheidung: Sie können eine "stack-Zuweisung" auf dem heap. Streng genommen, ich nehme stack allocation bedeutet, die tatsächliche Methode der allocation, anstatt die Lage der Verteilung. Wenn Sie die Zuordnung einer Menge Sachen, die auf der eigentlichen Programm-stack, das könnte schlecht sein für eine Vielzahl von Gründen. Auf der anderen Seite, verwenden Sie eine Stapel-Methode zum allokieren auf dem heap wenn möglich, ist die beste Wahl, die Sie machen können für eine Verrechnung.

Da Sie erwähnt Metrowerks und PPC, ich vermute, du meinst die Wii. In diesem Fall wird Speicher an einer Prämie ist, und mit einem stack-allocation-Methode, wo immer möglich, gewährleistet, dass Sie nicht verschwenden Speicher auf Fragmente. Natürlich, dies zu tun erfordert viel mehr Pflege als "normale" heap-allocation-Methoden. Es ist klug zu bewerten, die vor-und Nachteile für jede situation.

InformationsquelleAutor Dan Olson

Spezifischen Probleme in der Sprache C++

Zunächst es gibt keine sogenannten "stack" oder "heap" - Zuordnung, welche durch C++. Wenn Sie sprechen über die automatische Objekte in den Blockbereich, Sie sind noch nicht "zugeteilt". (BTW, automatische Speicherung Dauer in C ist definitiv NICHT das gleiche, "zugewiesen"; die letztere ist "dynamisch" im C++ - Jargon.) Und die dynamisch zugewiesenen Speicher ist auf der free store, nicht unbedingt auf den "heap", obwohl letzteres ist oft der (Standard -) Umsetzung.

Obwohl gemäß der abstrakten semantischen Regeln, die automatische Objekte noch Speicher belegen, ein konformer C++ - Implementierung erlaubt, um diese Tatsache zu ignorieren, wenn es nachweisen kann, dass dies nicht egal ist (wenn es sich nicht ändern das beobachtbare Verhalten des Programms). Diese Berechtigung ist durch die wie-wenn Regel in ISO C++, die auch der generalklausel ermöglicht die üblichen Optimierungen (und es ist auch eine fast gleiche Regel in ISO-C). Neben der als-ob-Regel ISO-C++ auch die copy elision Regeln, mit denen die Unterlassung von spezifischen Kreationen von Objekten. Der Konstruktor und der Destruktor ruft involviert sind, werden dabei weggelassen. Als Ergebnis, die automatische Objekte (wenn vorhanden) in diese Konstruktoren und Destruktoren sind auch abgeschafft, im Vergleich zum naiv-abstrakte Semantik implizit durch den Quellcode.

Auf der anderen Seite,, Kostenlose store-Aufteilung ist auf jeden Fall "Zuweisung" von design. Unter ISO-C++ - Regeln, eine solche Verteilung kann erreicht werden durch einen Anruf von einer Zuordnung Funktion. Aber seit ISO C++14 gibt es eine neue (nicht-als-wenn) Regel, die dies erlaubt die Zusammenführung global allocation-Funktion (d.h. ::operator new) fordert in bestimmten Fällen. So teilen die dynamische Zuweisung Operationen können auch no-op wie in dem Fall der automatischen Objekten.

Zuweisung Funktionen, Ressourcen Speicher. Objekte können weiter zugeteilt, basierend auf Zuweisung mit allocators. Für die automatische Objekte, Sie sind direkt präsentiert - obwohl der zugrunde liegende Speicher zugegriffen werden kann und verwendet werden, um Speicher, um andere Objekte (durch Platzierung new), aber das macht nicht viel Sinn, da der freie Speicher, denn es gibt keine Möglichkeit zum verschieben der Ressourcen anderswo.

Alle anderen Bedenken sind außerhalb der Reichweite von C++. Dennoch, können Sie immer noch erheblich.

Über Implementierungen von C++

C++ nicht aussetzen vergegenständlicht Aktivierung Datensätze oder einige Arten von erste-Klasse Fortsetzungen (z.B. durch die berühmte call/cc), es gibt keine Möglichkeit, direkt zu manipulieren die Aktivierungs-record-Rahmen - in denen die Umsetzung benötigen, um die automatische Objekte. Einmal gibt es keine (nicht-portable) interoperations mit der zugrunde liegenden Implementierung ("native" nicht-portablen code als inline-Assembler-code), eine Auslassung, die zugrunde liegende Zuordnung der frames werden kann, ziemlich trivial. Zum Beispiel, wenn die aufgerufene Funktion inlined, die frames kann man effektiv zusammengeführt in die andere, so dass es keine Möglichkeit gibt, um zu zeigen, was die "Zuordnung".

Jedoch einmal interops geachtet werden, die Dinge werden immer komplexer. Eine typische Implementierung in C++ setzen Sie die Fähigkeit der interop auf ISA (instruction set architecture) mit einigen Aufrufkonventionen als die binären Grenze gemeinsam mit der nativen (ISA-Ebene der Maschinen -) code. Dies wäre explizit zu teuer, insbesondere, wenn die Aufrechterhaltung der stack-pointer, die oft direkt statt, indem eine ISA-level-register (mit wohl spezifische Maschinenbefehle für den Zugriff). Der stack-pointer kennzeichnet die Grenze des oberen Rahmen des (derzeit aktiv) - Funktion aufrufen. Wenn eine Funktion aufgerufen wird eingegeben, wird ein neuer Rahmen benötigt wird, und der stack-pointer addiert oder subtrahiert (abhängig von der convention der ISA) durch einen Wert von nicht weniger als die benötigte Bildgröße. Der Rahmen wird dann gesagt zugeordnet, wenn der stack-pointer nach der Operationen. Parameter von Funktionen dürfen übergeben werden, auf den stack-Rahmen als auch, je nach Aufrufkonvention verwendet für den Aufruf. Die Rahmen können halten Sie die memory-automatische Objekte (wohl einschließlich der Parameter) angegeben, die von den C++ - source-code. In dem Sinne, Implementierungen, diese Objekte sind "reserviert". Wenn die Steuerung beendet den Funktionsaufruf, der Rahmen ist nicht mehr notwendig, es ist in der Regel frei durch die Wiederherstellung der stack-pointer wieder in den Zustand vor dem Aufruf von (zuvor gespeicherten nach der Aufrufkonvention). Dies kann gesehen werden, als "Freigabe". Diese Vorgänge macht der Aktivierungsstatus effektiv eine LIFO-Datenstruktur, so dass es oft als "die (call -) Stapel". Der stack-pointer effektiv zeigt die Obere Lage des Stapels.

Weil die meisten C++ - Implementierungen (vor allem diejenigen, die targeting-ISA-Ebene nativen code und über die assembly-Sprache, die als seine unmittelbare output) nutzt ähnliche Strategien wie diese, so verwirrend "allocation" - Regelung ist beliebt. Solche Zuweisungen (sowie deallocations) verbringen Maschine Zyklen, und es kann teuer werden, wenn die (nicht optimierte) ruft Häufig auftreten, auch wenn moderne CPU microarchitectures können komplexe Optimierungen implementiert in der hardware für die gemeinsame code-Muster (wie mit einem stack engine bei der Umsetzung PUSH/POP Anweisungen).

Aber trotzdem, im Allgemeinen, es ist wahr, dass die Kosten für die stack-frame-Zuordnung ist deutlich weniger als ein Anruf, um eine Zuordnung Funktion die Bedienung der free store (es sei denn, es ist völlig wegoptimiert), die sich Hunderte (wenn nicht Millionen 🙂 Operationen zur Aufrechterhaltung der stack-pointer und anderen Staaten. Zuordnung Funktionen sind in der Regel basierend auf API zur Verfügung gestellt, die durch die gehostete Umgebung (z.B. Laufzeit, sofern durch das OS). Verschiedene für die Durchführung von automatischen Objekten für die Funktionen Aufrufe, solche Zuweisungen sind allgemein-vorgesetzt, so dass Sie nicht haben frame-Struktur wie ein stack. Traditionell, Sie Speicherplatz von der pool-Speicher genannt heap (oder mehrere heaps). Anders als die "stack", der Begriff "heap" bedeutet hier nicht an, die Datenstruktur, die verwendet wird; es ist abgeleitet von der frühen Implementierungen von Programmiersprachen, die vor Jahrzehnten. (BTW, ist der call-stack ist in der Regel zugeordnet, die mit festen oder benutzerdefinierten Größe auf dem heap, indem Sie die Umwelt in Programm oder thread starten.) Die Art der Nutzung Fällen macht Zuweisungen und deallocations aus einem heap weit komplizierter (als push-oder pop stack-frames), und kaum möglich zu sein, direkt optimiert durch hardware.

Auswirkungen auf Memory Access

Den üblichen stack-Zuweisung legen Sie immer den neuen Rahmen auf der Oberseite, so hat es eine sehr gute Lokalität. Diese ist freundlich zu cache. OTOH, Speicher zufällig in der free store hat keine solche Eigenschaft. Da die ISO-C++17, es gibt pool-Ressourcen-Vorlagen zur Verfügung gestellt von <memory>. Der direkte Zweck dieser Schnittstelle ist es, die Ergebnisse von aufeinander folgenden Zuweisungen nah zusammen im Speicher. Dies bestätigt die Tatsache, dass diese Strategie ist im Allgemeinen gut für die Leistung, die mit modernen Implementierungen, z.B. freundlich zu cache in modernen Architekturen. Dies ist über die Leistung von Zugang eher als Zuordnung, obwohl.

Parallelität

Erwartung der gleichzeitige Zugriff der Speicher kann verschiedene Effekte zwischen den stapeln und Haufen. Ein call-stack ist in der Regel ausschließlich im Besitz von einem thread der Ausführung in eine C++ Implementierung. OTOH, die Haufen sind oft gemeinsamen unter den threads in einem Prozess. Für solche Haufen, die Reservierung und Freigabe-Funktionen haben, zum Schutz der gemeinsamen internen Verwaltungs-Daten-Struktur aus Daten Rennen. Als Ergebnis, heap-Zuweisungen und deallocations können zusätzliche overhead durch interne Synchronisation Operationen.

Raum Effizienz

Aufgrund der Natur von Anwendungsfällen und interne Datenstrukturen, heaps kann, leidet unter internen Fragmentierung des Speichers, während der Stapel nicht. Dies hat keine direkten Auswirkungen auf die Leistungsfähigkeit der Speicher-Zuweisung, aber in einem system mit virtueller Speicher, wenig Platz-Effizienz degenerieren die Gesamtleistung des Speicher-Zugriff. Dies ist besonders schrecklich, wenn HDD als swap physischen Speicher. Es kann zu sehr langen Wartezeiten - manchmal Milliarden von Zyklen.

Einschränkungen der Stack Zuweisungen

Stack Zuweisungen sind oft besser in der Leistung als heap-Allokationen in der Realität, es bedeutet sicher nicht stack-Allokationen können immer ersetzen Heapzuweisungen.

Erste, es gibt keinen Weg, um Speicherplatz auf dem Stapel mit einer festgelegten Größe, die zur Laufzeit in einem tragbaren Weise mit ISO-C++. Es gibt Erweiterungen zur Verfügung gestellt von Implementierungen wie alloca und G++'s VLA (variable length array), aber es gibt Gründe, um zu vermeiden, verwenden Sie. (IIRC, Linux-Quellcode entfernt Verwendung von VLA vor kurzem.) (Beachten Sie auch die ISO-C99 hat VLA, aber ISO-C11 stellt die Unterstützung optional.)

Zweite, es gibt keine zuverlässige und portable Weise zu erkennen stackspeichers. Dies wird Häufig als stack-überlauf (hmm, Etymologie dieser Website), aber wahrscheinlich mehr accruately, "stack overrun". In Wirklichkeit ist dies oft die Ursache Ungültiger Zugriff auf Speicher und den Status des Programms dann corruptied (...oder vielleicht noch schlimmer, eine Sicherheitslücke). In der Tat, ISO-C++ hat kein Konzept von Stapel-und macht es zu undefiniertem Verhalten, wenn die Ressource erschöpft ist. Seien Sie vorsichtig, wie viel Platz gelassen werden sollte für die automatische Objekte.

Wenn der stack-Speicher erschöpft, es gibt zu viele zugeordnete Objekte im stack, die verursacht werden durch zu viele aktive Aufrufe von Funktionen oder unsachgemäße Verwendung von automatischen Objekten. Solchen Fällen möglicherweise vorschlagen, die Existenz von bugs, z.B. eine rekursive Funktion aufrufen, ohne richtige exit-Bedingungen.

Dennoch, tief-rekursive Aufrufe sind manchmal erwünscht. In den Implementierungen der Sprachen, die Unterstützung der ungebundenen aktiven Anrufe (call-Tiefe nur begrenzt durch die Gesamtspeicherkapazität), es ist unmöglich Sie systemeigene Aufrufliste direkt als Zielsprache activation record wie typische C++ - Implementierungen. Zum Beispiel, SML/NJ explizit zuweist frames auf dem heap, und verwendet Kaktus-stacks. Die komplizierte Verteilung solcher activation record-frames ist in der Regel nicht so schnell wie die der call-stack-frames. Allerdings, wenn die Umsetzung weiterer Sprachen mit proper tail recursion, direkte stack Allokation im Objekt-Sprache (also das "Objekt" in der Sprache nicht als Referenz gespeichert, aber die Grundwerte, die kann eins-zu-eins zugeordnet ungeteilt C++ - Objekte) ist sogar noch komplizierter, mit mehr Leistung Strafe im Allgemeinen. Bei der Verwendung von C++ zu implementieren, die solche Sprachen, ist es schwierig einzuschätzen, die Auswirkungen auf die Leistung.

InformationsquelleAutor FrankHB

Möchte ich sagen, tatsächlich-code generieren, indem Sie GCC (ich erinnere VS auch) nicht haben overhead zu tun stack Allokation.

Sagen für folgende Funktion:

  int f(int i)
  {
      if (i > 0)
      {   
          int array[1000];
      }   
  }

Wird folgender code generiert:

  __Z1fi:
  Leh_func_begin1:
      pushq   %rbp
  Ltmp0:
      movq    %rsp, %rbp
  Ltmp1:
      subq    $**3880**, %rsp <--- here we have the array allocated, even the if doesn't excited.
  Ltmp2:
      movl    %edi, -4(%rbp)
      movl    -8(%rbp), %eax
      addq    $3880, %rsp
      popq    %rbp
      ret 
  Leh_func_end1:

So whatevery, wie viel lokale variable, die Sie haben (auch innerhalb der if-oder switch), nur die 3880 wird sich ändern zu einem anderen Wert. Es sei denn, Sie hat keine lokalen Variablen, die diese Anweisung nur ausführen müssen. So reservieren lokale variable, die nicht Aufwand haben.

InformationsquelleAutor ZijingWu