La gestione della memoria nella programmazione sta diventando una preoccupazione irrilevante?


38

Sfondo
Ho rivisitato un vecchio (ma fantastico) sito in cui non ero stato per secoli: l'Alioth Language Shootout ( http://benchmarksgame.alioth.debian.org/ ).

Ho iniziato a programmare in C / C ++ diversi anni fa, ma da allora ho lavorato quasi esclusivamente in Java a causa dei vincoli linguistici nei progetti in cui sono stato coinvolto. Non ricordando le cifre, volevo vedere approssimativamente quanto bene Java contro C / C ++ in termini di utilizzo delle risorse.

I tempi di esecuzione erano ancora relativamente buoni, con Java nella peggiore delle prestazioni 4x 4x più lento di C / C ++, ma in media circa (o inferiore) 2x. A causa della natura dell'implementazione di Java stesso, questa non è stata una sorpresa, e il suo tempo di prestazioni è stato effettivamente inferiore a quello che mi aspettavo.

Il vero mattone era l' allocazione di memoria - nel peggiore dei casi, Java allocata:

  • un enorme 52 volte più memoria di C
  • e 25 volte più di C ++.

52x il ricordo ... Assolutamente brutto, vero? ... o è? La memoria ora è relativamente economica.

Domanda:
se non parliamo di piattaforme target con limiti rigidi alla memoria di lavoro (ovvero sistemi embedded e simili), l'uso della memoria dovrebbe essere un problema quando si sceglie una lingua per scopi generali oggi?

Lo sto chiedendo in parte perché sto pensando di migrare su Scala come lingua principale. Mi piacciono molto gli aspetti funzionali, ma da quello che posso vedere è ancora più costoso in termini di memoria di Java. Tuttavia, poiché la memoria sembra diventare più veloce, più economica e più abbondante di anno in anno (sembra essere sempre più difficile trovare un laptop consumer senza almeno 4 GB di RAM DDR3), non si potrebbe sostenere che la gestione delle risorse sta diventando sempre più irrilevante se paragonato a funzioni linguistiche di alto livello (possibilmente costose dal punto di vista dell'implementazione) che consentono una costruzione più rapida di soluzioni più leggibili?


32
Non dimenticare che solo perché Java alloca 52 volte più memoria di C per un piccolo benchmark, ciò non significa che utilizzerà 52 volte più memoria per un'applicazione di grandi dimensioni. La parte del leone di quella memoria sarà una quantità fissa richiesta dalla JVM, e più grande diventa la tua applicazione, meno significativa sarà quella porzione.
Carson63000,

4
Se lo sviluppo mobile è irrilevante, allora sì.
JeffO

3
La domanda è: quanto è grave il benchmark Java rispetto a C / C ++ e cosa significa in termini di scelta tra le due lingue. Vedo questo come argomento, pertinente per tutti i programmatori, chiaro, mirato e in grado di rispondere ragionevolmente nella sua forma attuale. Ho votato per riaprire.
GlenPeterson

La maggior parte dei problemi di prestazioni sono causati e risolti a livello di progetto, non a livello di strumento. Alcuni problemi richiedono una granularità di 1ms e quindi richiedono C / C ++. Se hai margine di manovra, come 10ms, forse Scala o Java sono una buona opzione. La maggior parte dei controller di input per giochi funzionano a un livello di 50-100 ms. Molte persone oggi scrivono sezioni critiche in una lingua e il resto di un programma in un'altra.
GlenPeterson

4
Quando si guarda il "25x più del C ++" in questo test è necessario prendere in considerazione la costante aggiunta del tempo di esecuzione (circa 13 Mb). Man mano che il problema aumenta, il fabbisogno di memoria di runtime diminuisce in percentuale dell'intero programma. Laddove l'utilizzo della memoria C ++ è inferiore a 1 MB, se si sottrae l'utilizzo della memoria C ++ dall'utilizzo della memoria Java, si otterrà un valore abbastanza costante.

Risposte:


34

La gestione della memoria è assolutamente rilevante poiché governa la velocità con cui appare qualcosa anche se ha una grande quantità di memoria. L'esempio migliore e più canonico sono i giochi con titolo AAA come Call of Duty o Bioshock. Si tratta effettivamente di applicazioni in tempo reale che richiedono enormi quantità di controllo in termini di ottimizzazione e utilizzo. Non è l'utilizzo di per sé il problema, ma piuttosto la gestione.

Si riduce a due parole: Garbage Collection. Gli algoritmi di Garbage Collection possono causare lievi singhiozzi nelle prestazioni o addirittura bloccare l'applicazione per un secondo o due. Principalmente innocuo in un'app di contabilità ma potenzialmente rovinoso in termini di esperienza dell'utente in un gioco di Call of Duty. Pertanto, nelle applicazioni in cui il tempo conta, le lingue raccolte con immondizia possono essere estremamente problematiche. È uno degli obiettivi di progettazione di Squirrel, ad esempio, che cerca di porre rimedio al problema che Lua ha con il suo GC usando invece il conteggio dei riferimenti.

È più un mal di testa? Certo, ma se hai bisogno di un controllo preciso, lo sopporti.


14
-1 "... letteralmente letale in un gioco ..." - Il mio lavoro quotidiano è un sistema critico per la sicurezza come per la sicurezza della vita. Il peggio che succede nel software di gioco è che lo scrittore fallisce perché è schifoso e nessuno lo compra. Questa è una differenza che non dovrebbe essere banalizzata.
Mattnz,

4
@mattnz Scarsa scelta delle parole da parte mia. È stato corretto. Non era mia intenzione banalizzare nulla.
Ingegnere mondiale

19
@Mattnz: se hai familiarità con i giochi, significa ovviamente che potrebbe essere letale per il tuo personaggio , il che è un'affermazione completamente vera.
Mason Wheeler

8
+1 perché il risponditore ha un diamante, quindi la risposta deve essere corretta.
ps

8
I raccoglitori di immondizia in tempo reale esistono da secoli.
Jörg W Mittag

30

Il vero mattone era l'allocazione della memoria - nella peggiore delle ipotesi, Java aveva allocato una memoria 52 volte maggiore rispetto a C e 25 volte superiore a C ++.

Avete capito i numeri che basare la sua domanda su?

  • Quanta memoria è stata allocata?
  • Cosa stavano facendo i programmi?

Quando c'è una grande disparità tra quei programmi Java e C, è principalmente l' allocazione di memoria JVM predefinita rispetto a qualsiasi cosa sia necessaria la libc:


  • Programma Java n-body 13.996 KB :: Programma C 320 KB :: Free Pascal 8 KB

Guarda le attività che richiedono l' allocazione della memoria (o usa buffer aggiuntivi per accumulare risultati da programmi multicore):

  • mandelbrot
    Java programma 67 , 880 KB :: programma C 30 , 444 KB


  • Programma Java k-nucleotide 494 , 040 KB :: Programma C 153 , 452 KB

  • complemento inverso
    programma Java 511 , 484 KB :: programma C 248 , 632 KB

  • regex-dna
    programma Java 557 , 080 KB :: programma C 289 , 088 KB

  • programma binario alberi
    Java 506 , 592 KB :: programma C 99 , 448 KB

... l'uso della memoria dovrebbe essere un problema quando si sceglie una lingua per uso generale oggi?

Dipende se l' utilizzo specifico , per il tuo specifico approccio alla risoluzione dei problemi specifici che devi risolvere, sarà vincolato dai limiti specifici della memoria disponibile sulla piattaforma specifica che verrà utilizzata.


3
Il tuo punto di scavare nei numeri è valido e quel sito ha sicuramente alcune dichiarazioni di non responsabilità che circondano i loro test. La tua risposta sarebbe rafforzata affrontando direttamente la domanda principale, che è "l'uso della memoria dovrebbe essere una preoccupazione?"

1
Ottima risposta a una domanda relativamente scarsa (il benchmark vagamente specificato è anche peggio dell'ottimizzazione prematura :). I dati a supporto dell'analisi sono ben presentati, concreti e costituiscono un ottimo spunto di riflessione. Sicuramente merita una taglia "risposta esemplare" .
moscerino

17

Come per tutte le cose, è un compromesso.

Se si sta creando un'applicazione che verrà eseguita su un desktop per singolo utente e ci si può ragionevolmente aspettare che controlli gran parte della RAM su quella macchina, potrebbe valerne la pena sacrificare l'utilizzo della memoria per la velocità di implementazione. Se stai prendendo di mira quella stessa macchina ma stai costruendo una piccola utility che sarà in competizione con un sacco di altre applicazioni affamate di memoria che sono in esecuzione contemporaneamente, potresti voler essere più cauto su quel compromesso. Un utente può stare bene con un gioco che vuole tutta la sua memoria quando è in esecuzione (sebbene, come sottolinea l'Ingegnere Mondiale, " mi preoccuperò se il garbage collector decide di mettere periodicamente in pausa l'azione per fare una scansione) - è probabile che siano molto meno entusiasti se il lettore musicale che eseguono in background mentre fa altre cose decide di divorare un sacco di memoria e interferisce con la loro capacità di lavorare. Se stai creando un'applicazione basata sul Web, qualsiasi memoria che utilizzi sui server limita la tua capacità di ridimensionamento costringendoti a spendere più soldi su più server applicazioni per supportare lo stesso insieme di utenti. Ciò può avere un impatto importante sull'economia dell'azienda, quindi potresti voler essere molto cauto nel fare questo trade-off. qualsiasi memoria che usi sui server limita la tua capacità di ridimensionamento costringendoti a spendere più soldi su più server applicazioni per supportare lo stesso insieme di utenti. Ciò può avere un impatto importante sull'economia dell'azienda, quindi potresti voler essere molto cauto nel fare questo trade-off. qualsiasi memoria che usi sui server limita la tua capacità di ridimensionamento costringendoti a spendere più soldi su più server applicazioni per supportare lo stesso insieme di utenti. Ciò può avere un impatto notevole sull'economia dell'azienda, quindi potresti voler essere molto cauto nel fare questo trade-off.


8

Dipende da una serie di fattori, in particolare dalla scala a cui stai lavorando.

Per ragioni di argomento, ipotizziamo una differenza di 30 volte nella memoria e 2 volte nell'uso della CPU.

Se hai a che fare con un programma interattivo che richiederebbe 10 megabyte di memoria e 1 millisecondo di CPU se scritto in C, è praticamente irrilevante: l'esecuzione di 300 megabyte di memoria e 2 millisecondi è normalmente irrilevante su un desktop tipico, e difficilmente significherà molto anche su un telefono o un tablet.

La differenza tra la necessità di circa la metà delle risorse di 1 server e la necessità di 15 server è un passo molto più grande, soprattutto perché è probabile che lo sviluppo su 15 server richieda molto lavoro aggiuntivo per svilupparsi invece di meno. Per quanto riguarda l'espansione futura, gli stessi fattori che menzioni tendono a suggerire che, a meno che la tua base di clienti non subisca una crescita massiccia , che se verrà eseguita su un server ora, è molto probabile che quando superi quel server, sarai in grado di sostituirlo con un server più recente senza alcun problema.

L'altro fattore che devi davvero considerare è esattamente quanta differenza nel costo di sviluppo vedrai per il tuo compito specifico. In questo momento, stai praticamente guardando un lato di un'equazione. Per avere una buona idea dei costi rispetto ai benefici, è necessario (ovviamente abbastanza) esaminare sia i costi che i benefici, non solo uno isolato. La vera domanda è sostanzialmente: "x è maggiore di y?" - ma non puoi determinarlo guardando solo x. Devi chiaramente guardare anche te.


2
+1 per notare la scala. Dai un'occhiata a questo articolo per apprendere davvero la gestione delle risorse su larga scala.
Guy Coder

6

La gestione della memoria è assolutamente rilevante nel mondo di oggi. Tuttavia, non nel modo previsto. Anche nelle lingue raccolte con immondizia devi assicurarti di non avere una perdita di riferimento

Stai facendo qualcosa di sbagliato se questo è il tuo codice:

static List<string> Cache;

...
Cache.Add(foo); //and then never remove anything from Cache

La garbage collection non può magicamente sapere che non userete mai più alcun riferimento a meno che non lo facciate in modo da non poterlo usare più, cioè facendo Cache=null, avvisate efficacemente il garbage collector che "hey non sarò in grado di accedi ancora. Fai quello che vuoi con esso "

È più complicato di così, ma le perdite di riferimento sono altrettanto dannose, se non di più, delle tradizionali perdite di memoria.

Ci sono anche alcuni posti in cui non è possibile inserire un bidone della spazzatura. Ad esempio, ATTiny84 è un microcontrollore con 512 byte di codice ROM e 32 byte di RAM. In bocca al lupo! Questo è un estremo, e probabilmente non sarebbe programmabile in altro che assembly, ma comunque. In altri casi potresti avere 1 M di memoria. Certo, potresti adattare un garbage collector, ma se il processore è molto lento (o per limitazioni o per preservare la batteria), allora non vorrai usare un garbage collector perché è troppo costoso tracciare ciò che un programmatore potrebbe sapere .

Inoltre, diventa molto più difficile utilizzare la garbage collection quando sono necessari tempi di risposta garantiti. Ad esempio, se hai un cardiofrequenzimetro o qualcosa del genere e quando lo riceve 1su una porta, devi assicurarti di poter rispondere con un segnale adeguato o qualcosa entro 10 ms. Se nel mezzo della tua routine di risposta il garbage collector ha bisogno di fare un passaggio e finisce per richiedere 100ms per rispondere, potrebbe essere qualcuno morto. La raccolta dei rifiuti è molto difficile, se non impossibile, da utilizzare quando è necessario garantire i requisiti di temporizzazione.

E ovviamente, anche su hardware moderno, ci sono alcuni casi in cui hai bisogno di quel 2% in più di prestazioni non preoccuparti del sovraccarico di un garbage collector.


3

Come diceva Donald Knuth, l'ottimizzazione prematura è la radice di tutti i mali. A meno che tu non abbia una ragione per credere che la memoria sarà il collo di bottiglia, non preoccuparti. E dato che la legge di Moore sta ancora fornendo una maggiore capacità di memoria (anche se non stiamo ottenendo codice single-threaded più veloce da esso), ci sono tutti i motivi per credere che in futuro saremo ancora meno vincolati alla memoria di noi sono oggi.

Detto questo, se l'ottimizzazione non è prematura, lo faccia sicuramente. Sto lavorando personalmente a un progetto in questo momento in cui comprendo dettagliatamente il mio utilizzo della memoria, in realtà ho bisogno di un controllo preciso e una spazzatura mi ucciderebbe. Sto quindi facendo questo progetto in C ++. Ma quella scelta sembra essere un evento una volta ogni diversi anni per me. (Spero che tra qualche settimana non toccherò più C ++ per qualche altro anno.)


4
Questo atteggiamento è il modo in cui finiamo con un software aziendale gonfio su computer incredibilmente lenti che continuano a sfogliare. Tutti dicono "Certo che la mia app richiede più memoria, ma chi se ne frega, è praticamente gratis!" e poi ti ritrovi con una serie completa di app affamate di memoria che fanno funzionare una macchina RAM da 4 GB più lentamente rispetto a una macchina RAM da 512 MB 10 anni fa.
MrFox

@MrFox In realtà il problema con il software aziendale è che le persone che decidono di usarlo non sono le persone che ne soffrono. Vedi lists.canonical.org/pipermail/kragen-tol/2005-April/000772.html per una descrizione eccellente del perché è rotto. Per il resto, ti sei perso la mia precisazione che a volte è necessario preoccuparsi dell'utilizzo della memoria?
btilly

3

Per le persone che si occupano di gestione della memoria "big data" è ancora un grosso problema. Programmi in astronomia, fisica, bioinformatica, apprendimento automatico, ecc., Devono tutti gestire set di dati multi-gigabyte, e i programmi funzionano molto più velocemente se le parti pertinenti possono essere conservate in memoria. Anche l'esecuzione su una macchina con 128 GB di RAM non risolve il problema.

C'è anche la questione di sfruttare la GPU, anche se forse lo classificheresti come sistema incorporato. Gran parte del duro pensiero nell'uso di CUDA o OpenCL si riduce a problemi di gestione della memoria nel trasferimento dei dati dalla memoria principale alla memoria GPU.


1

Per essere onesti, molta Java là fuori si concede alcuni modelli veramente ed inutilmente esplosivi di classe che uccidono solo le prestazioni e la memoria del maiale, ma mi chiedo quanto di quella memoria sia solo la JVM che in teoria (eh) ti consente di eseguire il stessa app in più ambienti senza dover riscriverne completamente di nuovi. Da qui la domanda di compromissione del design si riduce a: "Quanto della memoria dei tuoi utenti vale un tale vantaggio di sviluppo per te?"

Questo è, IMO un compromesso perfettamente utile e ragionevole da considerare. Ciò che mi fa incazzare è l'idea che, dato che i PC moderni sono così potenti e la memoria è così economica, possiamo ignorare completamente tali preoccupazioni e caratteristiche e codice bloat ed essere pigri sulle scelte al punto in cui sembra un sacco di roba Faccio su un PC Windows ora, impiega tutto il tempo che ha fatto in Windows '95. Scherzi a parte, Word? Quanta nuova merda di cui l'80% della loro base di utenti ha effettivamente bisogno avrebbe potuto aggiungere in 18 anni? Abbastanza sicuro che avessimo il controllo ortografico pre-windows giusto? Ma stavamo parlando di memoria che non è necessariamente veloce se ne hai in abbondanza, quindi sto divagando.

Ma ovviamente se riesci a completare l'app in 2 settimane al costo di forse qualche megabyte in più anziché 2 anni per ottenere la versione solo per pochi K, vale la pena considerare come paragonano alcuni mega ( Immagino) 4-12 concerti sulla macchina degli utenti medi prima di schernire l'idea di essere così sciatta.

Ma cosa c'entra questo con Scala oltre la questione del compromesso? Solo perché si tratta di garbage collection, non significa che non dovresti sempre cercare di pensare al flusso di dati in termini di cosa sono gli ambiti e le chiusure e se dovrebbero essere lasciati in giro o utilizzati in modo tale che dislocato da GC quando non è più necessario. Questo è qualcosa che anche noi sviluppatori web dell'interfaccia utente JavaScript abbiamo dovuto pensare e speriamo continuerà mentre ci diffondiamo in altri domini problematici come il cancro esperto di perfetti (che tutti avreste dovuto uccidere con Flash o Applet o qualcosa quando ne avete avuto la possibilità) che siamo.


0

La gestione della memoria nella programmazione sta diventando una preoccupazione irrilevante?

La gestione (o il controllo) della memoria è in realtà il motivo principale per cui utilizzo C e C ++.

La memoria ora è relativamente economica.

Memoria non veloce. Stiamo ancora osservando un piccolo numero di registri, qualcosa come 32 KB di cache di dati per L1 su i7, 256 KB per L2 e 2 MB per L3 / core. Detto ciò:

Se non parliamo in termini di piattaforme target con limiti rigidi alla memoria di lavoro (ovvero sistemi embedded e simili), l'uso della memoria dovrebbe essere un problema quando si sceglie un linguaggio di uso generale oggi?

Utilizzo della memoria a livello generale, forse no. Sono un po 'poco pratico in quanto non mi piace l'idea di un blocco note che occupi, diciamo, 50 megabyte di DRAM e centinaia di megabyte di spazio su disco rigido, anche se ho quello da fare e altro ancora. Sono in giro da molto tempo e mi sembra strano e un po 'icky per me vedere un'applicazione così semplice prendere relativamente tanta memoria per ciò che dovrebbe essere fattibile con i kilobyte. Detto questo, potrei essere in grado di vivere con me stesso se incontrassi una cosa del genere se fosse ancora bello e reattivo.

La ragione per cui la gestione della memoria è importante per me nel mio campo non è quella di ridurre l'utilizzo della memoria in generale. Centinaia di megabyte di utilizzo della memoria non rallenteranno necessariamente un'applicazione in modo non banale se non si accede frequentemente a tale memoria (es: solo con un clic sul pulsante o qualche altra forma di input dell'utente, che è estremamente rara a meno che non si stanno parlando dei giocatori coreani di Starcraft che potrebbero fare clic su un pulsante un milione di volte al secondo).

La ragione per cui è importante nel mio campo è quella di avere una memoria stretta e ravvicinata a cui si accede molto frequentemente (es: essere in loop su ogni singolo frame) in quei percorsi critici. Non vogliamo perdere una cache ogni volta che accediamo a uno solo su un milione di elementi a cui è necessario accedere tutti in un ciclo ogni singolo frame. Quando spostiamo la memoria nella gerarchia dalla memoria lenta alla memoria veloce in blocchi di grandi dimensioni, diciamo linee di cache a 64 byte, è davvero utile se quei 64 byte contengono tutti dati rilevanti, se possiamo inserire più elementi di dati in quei 64 byte, e se i nostri modelli di accesso sono tali da utilizzarli tutti prima che i dati vengano sfrattati.

I dati a cui si accede frequentemente per il milione di elementi potrebbero estendersi a soli 20 megabyte anche se disponiamo di gigabyte. Fa ancora una differenza nel frame rate che scorre su quei dati ogni singolo frame disegnato se la memoria è stretta e stretta per ridurre al minimo i mancati cache, ed è qui che la gestione / controllo della memoria è così utile. Semplice esempio visivo su una sfera con alcuni milioni di vertici:

inserisci qui la descrizione dell'immagine

Quanto sopra è in realtà più lento della mia versione mutabile poiché sta testando una rappresentazione persistente di una struttura di dati di una mesh, ma a parte questo, ero solito lottare per raggiungere tali frame rate anche su metà di quei dati (è vero che l'hardware è diventato più veloce dalle mie lotte ) perché non ho avuto la capacità di minimizzare i mancati cache e l'uso della memoria per i dati mesh. Le maglie sono alcune delle strutture di dati più difficili che ho affrontato a questo proposito perché memorizzano così tanti dati interdipendenti che devono rimanere sincronizzati come poligoni, bordi, vertici, tante mappe di trama che l'utente desidera collegare, pesi ossei, mappe a colori, set di selezione, obiettivi di morph, pesi dei bordi, materiali poligonali, ecc. ecc. ecc.

Ho progettato e implementato numerosi sistemi mesh negli ultimi due decenni e la loro velocità era spesso molto proporzionale al loro uso della memoria. Anche se sto lavorando con così tanta memoria in più rispetto a quando ho iniziato, i miei nuovi sistemi mesh sono oltre 10 volte più veloci del mio primo progetto (quasi 20 anni fa) e in larga misura perché usano circa 1/10 di la memoria. La versione più recente utilizza persino la compressione indicizzata per stipare il maggior numero possibile di dati e, nonostante il sovraccarico di elaborazione della decompressione, la compressione ha effettivamente migliorato le prestazioni perché, ancora una volta, abbiamo così poca preziosa memoria veloce. Ora posso adattare un milione di mesh poligonali con coordinate di trama, cordonatura, assegnazioni di materiali, ecc. Insieme a un indice spaziale per esso in circa 30 megabyte.

Ecco il prototipo mutabile con oltre 8 milioni di quadrangoli e uno schema di suddivisione multires su un i3 con un GF 8400 (questo era di alcuni anni fa). È più veloce della mia versione immutabile ma non utilizzato in produzione poiché ho trovato la versione immutabile molto più facile da mantenere e il colpo di prestazione non è poi così male. Si noti che il wireframe non indica le sfaccettature, ma le patch (i fili sono in realtà curve, altrimenti l'intera mesh sarebbe nera uniforme), sebbene tutti i punti in una sfaccettatura vengano modificati dal pennello.

inserisci qui la descrizione dell'immagine

Quindi, comunque, volevo solo mostrarne alcuni sopra per mostrare alcuni esempi concreti e aree in cui la gestione della memoria è così utile e, si spera, anche così le persone non pensano che sto solo parlando dal mio culo. Tendo a irritarmi un po 'quando la gente dice che la memoria è così abbondante ed economica, perché si tratta di memoria lenta come DRAM e dischi rigidi. È ancora così piccolo e così prezioso quando parliamo di memoria veloce e le prestazioni per percorsi veramente critici (per esempio, caso comune, non per tutto) si riferiscono alla riproduzione di quella piccola quantità di memoria veloce e all'utilizzo nel modo più efficace possibile .

Per questo tipo di cose è davvero utile lavorare con un linguaggio che ti permetta di progettare oggetti di alto livello come C ++, ad esempio, pur potendo conservare questi oggetti in uno o più array contigui con la garanzia che la memoria di tutti questi oggetti saranno rappresentati contigui e senza alcun sovraccarico di memoria non necessario per oggetto (es: non tutti gli oggetti necessitano di riflessione o invio virtuale). Quando ci si sposta effettivamente in quelle aree critiche per le prestazioni, diventa effettivamente un aumento della produttività per avere tale controllo della memoria su, diciamo, armeggiare con pool di oggetti e utilizzare tipi di dati primitivi per evitare sovraccarico di oggetti, costi GC e mantenere l'accesso frequente alla memoria insieme contigui.

Quindi la gestione / controllo della memoria (o la loro mancanza) è in realtà una ragione dominante nel mio caso per scegliere quale linguaggio mi consente più efficacemente di affrontare i problemi. Scrivo sicuramente la mia parte di codice che non è critico per le prestazioni, e per questo tendo a usare Lua che è abbastanza facile da incorporare da C.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.