Perché abbiamo bisogno di un heap se tutto può essere fatto in modo molto più efficiente in pila?

Questo in realtà è in qualche modo correlato alla domanda che ho posto ieri sul perché sia ​​uno Stack che un Heap sono necessari nelle applicazioni che usiamo oggi (e perché non possiamo semplicemente andare con un Heap invece di entrambi, al fine di avere un semplice & standard singolare da seguire).

Tuttavia, molte delle risposte hanno indicato che uno Stack è insostituibile a causa del fatto che è molte centinaia (o migliaia) volte più veloce rispetto al tentativo di allocare / fare riferimento all'Heap. So che c'è un problema con l'allocazione dinamica della memoria se eliminiamo l'heap, ma non c'è un modo per aggirare questo, o forse, un modo per migliorare sullo stack in modo che possa gestire l'allocazione dinamica della memoria?

Il problema con gli stack è che non è possibile "liberare" la memoria a meno che non sia in cima allo stack. Ad esempio, supponi di aver assegnato 3 elementi di dimensioni diverse:

a = allocate(2000000); // 2000000 bytes
b = allocate(1);
c = allocate(5000000);

La pila avrebbe asul fondo, bnel mezzo e cin cima. Questo diventa problematico se vogliamo liberare b:

free(b); // b is not on top! We have to wait until c is freed!

La soluzione alternativa è spostare tutti i dati dopo be spostarli in modo che vengano dopo a. Funziona, ma richiederà 5000000 copie in questo caso - qualcosa che sarà molto più lento di un heap.

Questo è il motivo per cui abbiamo un mucchio. Mentre l'allocazione può essere più lenta di uno stack ( O(log n)vs O(1)), gli heap consentono di liberare la memoria in una posizione arbitraria O(log n), rispetto a uno stackO(n)

Lo stack è per thread, l'heap è a livello di processo

Se sono presenti 100 thread che elaborano tutti gli elementi di lavoro che inserisco in una coda, esattamente dove posso allocare gli elementi di lavoro in modo tale che uno qualsiasi dei 100 thread li possa vedere?

Esistono anche altri tipi di memoria

Ad esempio file mappati in memoria, memoria condivisa, I / O mappati (modalità kernel). L'argomento dell'efficienza è un po 'controverso in queste situazioni.

Uno stack è una struttura LIFO (last-in-first-out), in cima alla quale viene mantenuto un puntatore di riferimento (generalmente supportato dall'hardware). Detto questo, tutto ciò che si sta tentando di allocare nello stack anziché nell'heap dovrebbe essere una variabile locale in ogni funzione, nella parte superiore di questo stack. Quindi, la ragione principale contro uno stack è che la tua routine main () dovrebbe preallocare tutte le strutture di dati che il tuo programma utilizza (che dovrebbero essere in circolazione per l'intera durata del programma) in anticipo come tutte le strutture di dati allocate all'interno delle chiamate di funzione verranno infine rimosse quando tali chiamate di funzione ritornano e i loro frame o record di attivazione vengono espulsi dallo stack.

Gli stack funzionano alla grande per le allocazioni di memoria che obbediscono alle regole di LIFO (Last in First out), ovvero liberate la memoria nell'ordine inverso esatto in cui la allocate. LIFO è un modello di allocazione della memoria molto comune, forse il più comune. Ma non è l'unico modello, o anche l'unico modello comune. Per scrivere un programma efficiente in grado di affrontare un'ampia varietà di problemi, dobbiamo tenere conto dei modelli meno comuni, anche se ciò significa un'infrastruttura più complessa.

Se riesco a ottenere tutti i meta per un paragrafo: sei un principiante, come principiante apprezzi la semplicità e le regole in bianco e nero. Tuttavia, come principiante hai solo una visione spioncino della gamma di problemi e vincoli che devono essere sistemati dai programmi per computer. Stai entrando in una tecnologia che è stata in fase di sviluppo attivo per 75 anni. Non c'è niente di sbagliato nel chiedere perché le cose sono come sono, ma la risposta sarà generalmente "Sì, abbiamo provato il metodo semplice e diretto 50 anni fa, e si è scoperto che non funzionava molto bene per intere classi di problemi, quindi abbiamo dovuto fare qualcosa di più complicato ". Man mano che la tecnologia avanza, la semplicità deve generalmente lasciare il posto a efficienza e flessibilità.

Per un altro esempio, chiusure. Se impili pop, allora puoi perdere il record di attivazione della tua chiusura. Quindi, se vuoi che la funzione anonima e i suoi dati persistano, devi memorizzarla in un posto diverso dallo stack di runtime.

Tra le molte altre ragioni per l'allocazione dell'archiviazione heap.

Se si desidera restituire l'indirizzo di un oggetto a un programma chiamante, non si deve passare l'indirizzo di una variabile di stack, poiché la memoria dello stack verrà riutilizzata e possibilmente sovrascritta dalla successiva funzione chiamata. È necessario ottenere l'archiviazione richiesta utilizzando malloc () per assicurarsi che non venga sovrascritto dalle chiamate alle funzioni successive.

Puoi passare gli indirizzi degli oggetti dello stack dalla tua funzione alle funzioni che chiami, perché puoi garantire che esistano fino a quando il tuo programma "restituisce ()". Ma non appena la funzione ritorna, tutto lo stack di archiviazione è disponibile.