Intr-adevar, un memory manager scris bine poate fi mai eficient decat malloc/free, dar pentru ce? Un programator bun foloseste alocare dinamica numai cand are nevoie (aka nu abuzeaza) si nici nu provoaca leakuri (care pot fi usor depistate folosind un tool oarecare).

Sincer, am scris un memory manager si sa mor daca imi dau seama de ce.

Pai de ce te-ai apucat sa-l scrii? Si mai ales, pe ce te-ai bazat cind l-ai scris? Ca doar nu te-ai apucat sa faci unul fara sa ai un scop, de exemplu sa faci alocarile mici si fixe sa fie eficiente.

Un alocator custom se scrie pentru ca:

1. Nu toti programatorii care lucreaza la proiect sint disciplinati.

2. STL-ul nu-i deloc disciplinat daca e folosit de programatori nedisciplinati.

3. E destul de usor sa scrii un alocator mai rapid decit ce vine in CRT-ul multor compilatoare daca observi anumite caracteristici ale codului tau.

4. Codul "disciplinat" este asa pentru ca aloca mult si face singur management la bucata aia - ignorind, evident, cazurile penale cu malloc(sizeof(int)). Daca ai un alocator care stie despre ce e vorba, poti sa faci asta intr-un singur loc, nu sa duplici codul ala care face bucketing si reusing si ce-o mai face in 20 de locuri.

5. Poate vrei profiling, adica sa stii in fiecare moment cita memorie e folosita pentru lightmap-uri, cit e pentru normal map-uri, cit e pentru geometrie, cit e pentru AI, etc. Zic "poate" la misto, ca evident ca vrei daca ai un buget de memorie.

6. Poate iti trebuie vreun feature mai ezoteric, cum ar fi sa fie lock-free. Foarte multe structuri de date lock-free sint nedisciplinate si au nevoie sa aloce memorie per-element (ca STL-ul). Daca alocatorul nu e lock-free (ala din CRT-ul Microsoft, nu e, de exemplu), degeaba ai algoritmi lock-free de cozi si tree-uri, ca nu vor fi de fapt lock-free. In cazul asta vei avea nevoie de un alocator mai eficient (ca-l tot chemi) si lock-free, adica pui mina si scrii.

7. Or mai fi si altele, da' e in functie de proiect.

L-am scris la misto (ca nu aveam ce face ) si cu ocazia asta am mai invatat cate ceva. Nu am plecat de la o problema ci de la o idee (hai sa vad cum as face un MM eficient). Ca am ajuns la concluzia ca nu imi e folositor e altceva.

Un programator indisciplinat poate sa foloseasca drujba de 20 cai putere pe post de topor, oricat de user friendly ar fi. Daca vrea muschiul lui tot o sa dea malloc la vectori de 10 caractere sau matrici de transformare si chiar daca da free tot primeste o penalizare destul de mare decat daca ar folosi stackul.

Profilingul ar fi, intr-adevar, un plus important, dar inaplicabil in cazul meu (pana acum mi-a mers cu foaia si pixul - marturia complexitatii proiectelor mele ).

PS: Nu sunt lamurit de ce tot pomenesti de STL. Eu inteleg prin memory manager un modul care se ocupa cu alocarea/dealocarea/managementul/defragmentarea/etc blocurilor de memorie.

LE: WTF, forumul imi mancase o parte din mesaje o_O

Daca chiar ai nevoie de 10 caractere e perfect OK sa aloci 10 caractere. Nu-i OK sa le aloci daca ai nevoie de ele in aceeasi functie, da' daca ai nevoie de ele si dupa ce functia iese, n-ai ce sa faci decit sa le aloci. Poti sa te apuci sa folosesti un pool pe care-l manageruiesti tu, si sa duplici codul asta in urmatorul loc unde ai nevoie sa aloci blocuri mici, sau poti sa ai un alocator optimizat pentru blocuri mici, in care alocarile te costa un function call si doua accese la memorie si sa fii fericit in tot codul.

Sigur ca poti omori orice alocator, oricit de destept ar fi el, dar programatorii slabi nu-s malefici. Sint doar slabi, si gresesc previzibil. Cind te trezesti cu un proiect de sute de mii de linii cu malloc-uri peste tot care se vad in profile, un alocator custom poate fi o solutie mult mai ieftina decit sa te duci si sa repari tot codul. Nu va fi optima, da' te poate ajuta sa pui jocul in cutie. Pina si-n cazul ideal cind ai numai programatori buni in jur, tot trebuie sa aloci memorie, si atunci e bine sa fie o operatiune eficienta si e frumos sa stii ca codul ala de pooling pe care ar trebui sa-l scrie programatorii buni de fiecare data cind chiar trebuie sa faca alocari mici e intr-un singur loc.

Tot pomenesc de STL pentru ca in spatele multor chestii din STL se ascund alocari de memorie. std::list, std::map si restul trebuie sa faca o alocare per element (singurul container care nu are boala asta e std::vector). Chiar daca faci un std::map de integeri la integeri, tot o sa-ti aloce odata per element, ca in map nu bagi integeri, ci niste structuri care au cheia, valoarea, pointerii spre stinga si dreapta si culoarea nodului din red-black tree. Ideal e sa nu folosesti containerele astea ci sa ai versiuni "intruzive" care se bazeaza pe faptul ca elementele contin membrii necesari, da' nu traim in lumea ideala. Si slavitul std::string e vinovat de alocari, ca trebuie sa tina si el string-ul ala undeva. In CRT-urile civilizate are un mic buffer intern ca sa nu aloce pentru string-uri minuscule, da' in general e de ordinul a 8-10 bytes. Daca bagi 11 caractere intr-un std::string, o sa faca un minunat malloc(12). Fara a intra in filosofii despre motivele pentru care ai folosi std::string intr-un joc (nu exista scuze), cert e ca apare, si daca apare si-n profile e mai usor sa-i bagi pe git un alocator in care sa ceri si sa eliberezi 12 bytes e practic moca.