Referenciaszámlált memóriakezelést hoz majd Androidra a következő Delphi
2013-09-04T14:34:33+02:00
2013-09-05T15:27:22+02:00
2022-06-29T16:06:29+02:00
  • Nem hiszed el, de pont tegnap futottam bele ebbe a problemaba, csak nem tudtam, hogy mi lehet az oka, hát ez.

    Eddig olyasmiket raktam fel thread-ekbe, amiben nem volt lock es nagy mennyisegu statikus adattal dolgoztak es megszoktam, hogy 100% a cpu. Aztan tegnap tunt fel, hogy egy olyan projectnel, ahol rengeteg dinamikus cuccal dolgozok a CPU% csak 40-70.

    Kiprobaltam a ScaleMM-et (most mar van stable verzio) egy kis teszt appal es nagyon szepen hozza a 100%-ot! (Eloszor kaptam egy OutOfMemory-t, de az a teszt, ami még FastMM-en elment, itt eppenhogy nem. Az nem gond, ha mondjuk 25-50%-al nem annyira helytakarekos mint a FastMM. Lenyeg, hogy meghajtsa a core-okat.

    Thx a hasznos kommentet!
    Mutasd a teljes hozzászólást!
  • "Kiveszi a döntést a fejlesztő kezéből"
    Egyetertek. Azt hiszik meg lehet sporolni azt a koltseget. Illetve meg, de azt a felhsznalo fizeti meg.
    Mutasd a teljes hozzászólást!
  • A FastMM sem az igazi, a BrlndMM-nél tény hogy jobb, de messze van a megfelelőtől.

    Olvassgass :
    Delphi Haters' Blog: Core Values: Threading Problems
    Delphi doesn't like multi-core CPUs (or the contrary) - Synopse
    scalemm - Fast scaling memory manager for Delphi - Google Project Hosting
    http://delphitools.info/2011/10/13/memory-manager-investigations/

    Én mindenesetre nem vagyok híve sem a RefCount-nak, sem GC-nek. Kiveszi a döntést a fejlesztő kezéből.
    Mutasd a teljes hozzászólást!
  • WOW :) Nem is tudtam h ilyen van... Igen.. valami ilyet azert el tudnek kepzelni..
    Mutasd a teljes hozzászólást!
  • Amugy azt ma sem értem, hogy a GC helyett miert nem irnak inkabb egy roh4dtgyors es takarekos memory managert?

    A Delphi-ben a D2009-tol kezdve pont egy ilyen van, a FASTMM: Alacsony overhead (ha 10% folé megy már adogatja is vissza a blockokat az OS-nek), ertelmes realloc strategia, 3 féle pool: small, medium, large. A small-on belul kulon sorakoznak a 8,16,24,stb byte meretu dolgok a gyors elerhetoseg miatt. Van allithato align. Program kilepeskor leak report, ami megmondja, hogy milyen object-bol hany nem lett felszabaditva. Futas kozben meg memoria allokacios terkep. Egy ilyen mellett mi szukseg van egy - az önfejűsége miatt sokat szidott - GC-re? :D
    Mutasd a teljes hozzászólást!
  • Jol megfogalmaztad a 2 fele szivargast, koszonom. Viszont a felhasznalo szemszogebol ugyanaz az eredmeny.

    Valoszinuleg kesobb amikor a mobilokban is tizesevel merjuk a gigagat akkor nem lesz problema h 1 notepad par gigat beszed... de manapsag elkepeszto minoseget produkalnak nem garazs cegek is! Lasd eclipse, vagy a Mail OSX-ben.
    Mutasd a teljes hozzászólást!
  • OFF

    nem lehet stack-en objektum, ami automatikusan megszünik, amikor elveszti a scope-ot.


    Azt hittem, pont erre találták ki a struct-okat. Bár igaz, hogy nekik meg nem lehet destruktoruk.

    ON

    Vagyis hiszek benne, hogy hosszabb távon a GC irány előnyösebb (a nem hagyományosan C++ területeken), mint pl. a RefCount irány.


    Nekem pont azért szúrt szemet a "GC-nél hatékonyabb memóriakezelés" kifejezés, mert olyanokról olvastam, hogy a referenciaszámlálás kevésbé hatékony, mint a referenciakövetés (azaz a "szokásos GC"). A referenciaszámlálós megoldásoknak mindig bele kell írniuk a memóriába, ha referencia keletkezik vagy megszűnik, és mindezt lehetőleg szálbiztosan kell megoldaniuk. Ráadásul még így sem képesek lekezelni a ciklikus referenciákat, ezért előfordul, hogy a referenciaszámlálós rendszerbe csak be kell vezetni egy másodlagos referenciakövetős GC-t (amiről én személy szerint tudok, az a PHP és a Python, de biztos van más is).

    Persze attól is függ, hogy mit veszünk a hatékonyság mértékének. Az az esetek nagy részében igaz, hogy egy referenciaszámlálós rendszer kevesebb objektumot tart a memóriában, mint egy referenciakövetős, tehát ilyen szempontból hatékonyabb. Az is biztos, hogy determinisztikusabb, tehát jobb felhasználói élményt tud nyújtani, de ez meg már nem a hatékonyság kérdésköre.
    Mutasd a teljes hozzászólást!
  • Azért élesen különíts el két 'fajta' memória szivárgást.

    -- allokálás felszabadítás nélkül, mert a programozó hibázik és elfelejtette (alloc és soha nincs rá free, sőt akár a foglalt terület pointere is elveszett, nincs is min keresztül felszabadítani). [coder szint]
    -- allokálás és soha fel nem szabadítás, mert a programlogikában nem figyelt a programozó, hogy a szükségtelenné vált objektumokra (heap foglalásokra) ne legyenek hivatkozások. [designer szint]

    Az elsőre segítséget ad a GC vagy RefCount. A figyelmetlenségeket automatizmussal korrigálja.
    De a második eset továbbra is emberi tervezés, kivitelezés kérdése és nem automatizálható.
    [legfeljebb célra szabott tároló osztályok írásával/választásával, mintegy újabb segítő réteg bevezetésével kevesebb adminisztrációt, jobb központosítást lehet elérni, de ettől továbbra is a tervező dönt]

    ----

    Mint C/C++ felől közelítő, először a C#-ban felettébb idegesített, hogy a destructor nem igazi destructor, nem lehet stack-en objektum, ami automatikusan megszünik, amikor elveszti a scope-ot.

    De kezdem hinni, hogy a mobil eszközökön is annyi többlet memória és proc.mag [felesleg is!] lesz hamarosan, hogy a többszintű GC rendszerek 'memória pazarlása' valójában sebesség növekedésként jelenik meg.
    Ha nem adatbázis motorban vagy 3D engineben gondolkodunk, akkor a user interactio pont arra jó, hogy amikor 'dolgozni kell', akkor egye a memóriát és ne gondolkozzon a felszabadítással, amikor meg egy művelet végére ér (pl. userre vár, netes választ kér stb.) akkor ráér felszabadítgatni.
    [persze ehhez nem árt a GC stratégiák további fejlesztése és az oprendszerrel erősebb kapcsolat kialakítása]

    Vagyis hiszek benne, hogy hosszabb távon a GC irány előnyösebb (a nem hagyományosan C++ területeken), mint pl. a RefCount irány.
    Mutasd a teljes hozzászólást!
  • Nem latom a kulonbseget h az alkalmazas takarit kilepeskor v az oprendszer.


    Kibeszél itt kilépésrol?
    Mutasd a teljes hozzászólást!
  • Arra szeretnek utalni h az operacios rendszer kitakaritja az alkalmazas utan a memoriat, legalabbis win7 alatt amikor az idojaras jelzo gadget hirtelen megevett 5gb-t akkor kivancsisagbol megvartam mennyi ido alatt tudom bezarni. Kb 10perc alatt bejott a taskmanager es ki tudtam loni. Teljesen felszabadult a memoria az alkalmazas utan. De ugyanezt gondolom linuxrol is. Szoval az ilyen viselkedest marmint a memoria hasznalat novekedeset mi 15eve memoria szivargasnak hivtuk. Nem latom a kulonbseget h az alkalmazas takarit kilepeskor v az oprendszer. Sztem ilyen smartpointeres, referencia szamlalos esetben is kell torodni a memoriaval uvyanugy! Ellenkezo esetbe lasd a peldam mi tortenik. A velemenyem szerint kicsit is bonyolult program eseten mar nem lehet meguszni a memoria kezelest barmilyen prog nyelvet es memoria managert hasznal az ember...
    Mutasd a teljes hozzászólást!
  • Igen ám, de a cikk nem GC-rol szol, hanem arrol, hogy minden azonnal felszabadul, amint a scope-jabol kilepett a program. Pont, mint ezelott a copy-on-write stringek, meg az arrayok, az interface-ek, es az - ole, azaz idispatch vagy a sima - variantok csak most mar ebbe a korbe bekerulnek az objektumok is.
    Tehat ha egy funct-ban lefoglalsz egy akarmit es azt nem adod át a functon kivulre, akkor annak a refcountja a funct vegen pontosan 1 lesz es automatikusan, azonnal fel fog szabadulni.
    Bizonyos helyeken nem kell majd explicit free-ket beirogatni. Persze emiatt az ilyen uj programokat leforditva az eddigi platformokon garantalt memory leak lesz az eredmeny lol.
    (En is utalom a böszmenagy de minimalis funkcionalitasu programokat, mint pl. a kedvencemet a Catalyst Control Centert, de ez a (most mar mindenre) referenciaszamlalt memoriakezeles pont az ellenkezo iranyba mutat, ez még akkor is azonnal felszabadit, ha te elfelejted. :D A koltsege pedig +1 int minden egyes TObject-ben, na meg a refcounter automatikus karbantartasa, pont mintha ez egy interface lenne.)
    Mutasd a teljes hozzászólást!
  • Én azért várom. Az Android-sdk és Java ismerkedésem nem volt éppen zökkenőmentes (A HelloWorld tutorial végigcsinálása közben közölte, hogy korrupt lett egy XML a projektben, javítsam már ki...)
    Mutasd a teljes hozzászólást!
  • Ez nem garancia a minosegi alkalmazasok elkeszitesere sajnos. Sot..

    Most inditottam ujra OSX alatt a Mail-t mert a kezdeti 90MB helyett mar 1.5GB fele jart a memoria hasznalata es az ilyen vacakok miatt 16 GB kezdett megtellni.

    De a java-s Momentics is hasonlo "jo" tulajdonsaggal bir. (A gepemen)
    Mutasd a teljes hozzászólást!
abcd