gord napsal/a:
Ja mam pocit z drivejska, kdyz jsem s tim trochu laboroval, ze mi GG nejak obsadi nebo defragmentuje pamet
Viz. informace na Geoget-Dev. Statistika importu fragmentuje pamet, respektive zustane po ni naalokovano velmi mnoho malo vyuzitych bloku. Ve vyvojove verzi je to uz predelano tak, aby k tomu nedochazelo.
Tato rozfragmentovana pamet se da i v soucasne verzi uvolnit tim, ze smazes statistiku importu, treba volanim GeoImportBegin.
gord napsal/a:
Podle me v Pascalu implementovana prace se stringem nepatri k pvedenym, ale delat si vlastni, to se mi nechce Udelal jsem si ji pokusne pro zpracovani jednoho velkeho souboru (180 MB) a rychlost
Chyba lavky! Implementace stringu je v Pascalu nejlepsi a nejuspornejsi, jakou jsem kdy potkal. Ony ty nastinene problemy s tim stringem ve skutecnosti nijak nesouvisi. Je to obecny problem spravy pameti ve specifickych podminkach, tedy zalezitost memory-manageru.
Kdyz potrebujes zvetsit string, a misto v pameti za nim je necim obsazene, tak chte-nechte musis neco v pameti prehazet. A to trva. S tim ti zadna jina implementace nemuze pomoci. Jiste muzes namitnout, ze si lze alokovat string tam, kde jej pak muzes rozsirovat. Jenze jak velke misto si mas rezervovat? Kdybys tohle delal obecne, tak spotreba pameti radikalne vzroste.
Takze rozumne je to delat jen na explicitni pozadavek, kdy programator vi, kolik pameti bude potrebovat. No, a to se soucasnou implementaci muzes taky!
Jina cesta je, ukladat si string fragmentovane v nekolika blocich. Jenze to zase neni kompatibilni s null-terminated stringy, ktere holt, kvuliva C-cku, potrebujes na kazdem rohu. Jiste se cesta stringu v nekolika blocich muze zdat zajimava, ale prave onu velkou spotrebu pameti po importu v Geogetu zpusobil presne tento princip! To jsou paradoxy, co?