> Si pentru informarea ta: un bloc de memorie alocat nu este alocat cu
> adevarat decat in momentul in care e folosit. Asa ca pot sa aloc si sa
> dealoc 1G de memorie de 100k pe secunda.
Depinde cum aloci, pentru ca una este sa apelezi de tz ori
functia_mea_care_aloca_memorie(parametri) si una este sa ai
spre exemplu variabila prealocata si tu doar la nevoie scrii in ea.
Apelul ala de functie te pierde destul de tare, in cazul in care nu
stiai.
Poti sa citesti un fisier citind blocuri de cite n bytes in felul
urmator :
aloca n bytes
open fisier
cit timp not eof
citeste n bytes
fa ceva cu bytes
close fisier
SAU
open fisier
cit timp not eof
aloca n bytes
citeste n bytes
fa ceva cu bytes
dealoca bytes
close fisier
tu care varianta crezi ca e mai eficienta, huh ?!
pentru fiecare apel de functie se consuma destul de mult timp pentru
plasarea pregatirea parametrilor pe stiva, pentru apel, etc.
Idem la iesirea din functia apelata.
De-asta s-au si inventat macrourile si functiile inline, tocmai
pentru a diminua efectele produse de apelul in nestire al functiilor
acolo unde nu este necesar.Crezi ca mallocul ala al tau nu face nimic ?
Si daca lucrurile sint atit de roz pentru tine de ce crezi ca
se streseaza unii sa produca biblioteci dedicate de management al
memoriei, optimizate pentru aplicatii care au obiceiul sa aloce/dealoce
foarte frecvent memoria ?
Si de ce crezi ca se streseaza cei care scriu playerele de filme despre
care vorbesti tu sa bage cod in assembler pentru anumite operatiuni
critice ? Vezi mplayer si bucatile de cod cu mmx/sse/sse2/3dnow ?
Ti-am zis, cazul concret de fata probabil nu intra in regula asta, insa
ceea ce m-a deranjat a fost atitudinea, adica "pm ce conteaza pe
masinile din ziua de azi... "
La urma urmelor hai sa facem codeci scrisi in bash. Cu siguranta ca vor
functiona impecabil pe viitoarele masini pentium 5 sau amd K9.
Nu ?
---
Detalii despre listele noastre de mail: http://www.lug.ro/
