Aktív témák
-
Alan
aktív tag
Direct Oracle Access, ugye? Én is jókat hallottam róla. Szerencsére nekem egyelőre nem kell Oracle-lel érintkeznem.
Ne ijedj meg, de tényleg nem javaslom a ProcessMessages() használatát, most is valószínűleg csak azért működik tőle a programod, mert belehív egy másik eseménykezelődbe, ami szintén mozgatja a detail dataset kurzorát (persze így látatlanban nehéz megmondani, mitől hibás egy kód). Ettől viszont egy másik példányban is belelépsz a saját kódodba, és vagy tényleg reentráns az egész programod, vagy előbb-utóbb baj lesz. Próbáld ki pl.., hogy nagyon nagy táblákból töltöd fel a VT-t, úgy, hogy a feltöltés több másodpercig tartson, és eközben nyomkodj vadul a felhasználói felületen, lehetőleg a VT komponenst érintő dolgot csinálj. Szinte garantált a lefagyás vagy az AV.
Szerintem inkább csináld azt, hogy feltöltés után lerendezed az adott master node-ok alatti detail node-okat (ha az AutoSort nem működik, bár nálam ment az is). Ehhez a master és a detail node-okban is tárold el az elsődleges kulcsot az adott táblából. Hacsak nem lesz több ezer detail node egymás alatt, ez nem fogja érzékelhetően lerontani a teljesítményt - ha meg igen, akkor felhasználói szempontból úgyis használhatatlan lesz a program, mert egy egy szinten több ezer elemű tulajdonságfa kezelhetetlen.
Ha nem sértelek meg vele, ideírom neked a létező leggyorsabb rendezést (csak hogy ne kelljen annyit körmölnöd) :) :
[code]
procedure QuickSort(L, R: integer);
var
I, J: Integer;
T: TLaoCeTombocske;
begin
repeat
I := L;
J := R;
while LaoCeForrasTombocske < LaoCeForrasTombocske[(L + R) shr 1] do
Inc(I);
while LaoCeForrasTombocske[J]> LaoCeForrasTombocske[(L + R) shr 1] do
Dec(J);
repeat
if I <= J then
begin
T := LaoCeForrasTombocske;
LaoCeForrasTombocske := LaoCeForrasTombocske[J];
LaoCeForrasTombocske[J] := T;
Inc(I);
Dec(J);
end;
until I > J;
if L < J then
QuickSort(L, J);
L := I;
until I >= R;
end;
[/code]
Az L, R paraméterek a két szélső elem, a közöttük elhelyezkedő elemeket rendezi a rutin. Ha mindet akarod, akkor n elemű LaoCeForrasTombocske esetén így hívd meg: QuickSort(0, n-1); -
Alan
aktív tag
A jó híreknek nagyon örülök, főleg annak, hogy a lelkesedésed visszatért. Tudom, milyen érzés, amikor folyton az unalmas vackokat gyártod és nincs időd az érdekes dolgokra.
Helyi, egyedi felhasználáshoz, megosztani nem kívánt Access adatbázishoz teljesen jó lesz az ADO. Azért azt tudd, hogy az ADO komponensek a legbugosabbak az összes adatbázis-kezelőelem közül, de szerintem azért bőven használhatók. A hiba, amit tapasztaltál ADO tábláknál, erősen komponenshiba-gyanús egyébként, főleg, ha Oracle táblákkal (tehát, gondolom BDE-n vagy dbExpress-en keresztül nincs gond). Én nem dolgozom ADO komponensekkel, de a helyedben rákeresnék a groups.google.com-on, hogy másvalaki nem látott-e hasonlót (master-detail, lekérdezés sorrendje nem mindig jó).
Jól felépített programba elvileg sosem kell ''kézi'' ProcessMessages(). A legtöbbször, amikor ez valami hibát ''kijavít'', akkor csak elleplezi és más helyzetben visszajön. Sőt, ettől a hívástól az eseménykezelők újrahívódhatnak, miközben egy előző eseményt kezelsz - ergo a teljes programnak reentránsnak kell lennie (mintha többszálú lenne: globális elemeknél be kell, hogy játsszanak a kritikus szakaszok, mutexek és társaik), mert különben jön a váratlan, debugolhatatlan, időzítéstől/egérpozíciótól stb. függő, hajkitépető access violation.
Küldhetnél egy képernyőfotót, hogy lássam a cuccodat működés közben :) -
Alan
aktív tag
Remek, szuper :)
Nálam remekül megy a program, gondolhatod, hogy nem küldöm el kipróbálatlanul. Elindítás után a master tartalmát látod, sok pluszjellel, amiket ha lenyitogatsz, jönnek a 2-4. oszlopokban a detail mezők gyönyörűen. Lehet, hogy használtam valami specialitást (merthogy nálam már átdolgozott advanced Alan-féle VirtualTree megy ám), amire nem is figyeltem, vagy az is lehet, hogy Neked valami régebbi verzió van meg és azért nem működött elsőre
De a végső lényeg persze az, hogy a Te programod menjen jól. Majd jelentkezz, kíváncsi vagyok :) -
Alan
aktív tag
Hát, nem mondhatnám, hogy az élvezetek tengere ez a hétvége, de azért messze nem katasztrófa.
Gyorsan összeütöttem neked egy Virtual Treeview példaprogramot, amit el is küldök levélben. A szokásos BDE demó adatbázisokkal megcsinálja, amit akartál. Ha még van valami gond, nyugodtan szólj, ha tudok, segítek :) -
Alan
aktív tag
valamiert vegtelen ciklusba kerult, ha az InitChildren-ben queryt futtattam (lehet hogy en voltam bena, de az olasz srac is panaszkodott erre).
Ennek elvileg nem szabadna így lennie, ez az esemény direkt ilyen célra van. Talán a kódodban van valami hiba, ami miatt kiváltódik még egyszer ez az esemény (vagy egy másik, ami közvetve újra kiváltja ezt).
nem biztos hogy van children minden root node-hoz ugye. szoval akkor nem allithatom be az InitialStates -t maskent, csak ha tudom mar elore, hogy lesz-e gyereke.
OK, de először próbáld ki úgy, hogy mindegyiknél beállítod, mintha lenne, aztán ha mégsincs (OnInitChildren), akkor lenyitáskor törlöd a kis pluszjelet. Nem a legszebb, de a leggyorsabb megoldás, főleg mivel...
ezert gondoltam, hogy mar a root select (a rootnodehoz) kellene tartalmazza hogy melyik rekordnak hany gyereke van (count+group by), es itt, az InitNodeban egy selecttel rovidebb lenne a kod.
...különben be kell nyelned az egész adatbázist (de legalábbis minden subselect RecordCount-ját) már a legelején, így komolyabb adatbázisokhoz nem lesz használható a program. -
Alan
aktív tag
Még egy apróság: az AddChild, InsertNode és hasonlók csak azért vannak benne a VT-ben, hogy ne ijedjen el mindenki első látásra, de ezek lerontják a teljesítményt, csak a TTreeView-ra már ''rászokott'' felhasználók kedvéért, kompatibilitási okból van benne és egy idő múlva Mike Lischke valószínűleg ki fogja venni a komponensből. Szóval ezeket inkább ne használd.
Érdemes amúgy elolvasgatni a súgóját (Virtual Tree.chm), van pár jó példa benne. -
Alan
aktív tag
Hát, nem biztos, hogy akkora mázli, mert így az első két olvasás után attól tartok, rossz híreim vannak.
A VT működését jól értelmezed, valóban ezért villámgyors, de adatbáziskezeléshez nyers formában nem a legoptimálisabb, mert azon alapul, hogy a memóriában lévő adatstruktúrádból Te magad veszed majd elő neki az adatot (OnGetText) jó gyorsan, így nem kell az adatokat neki még egyszer letárolnia valahol (mint azt a ''klasszikus'' TTreeView teszi). Ha az OnGetText eseménykezelőben Te adatbázishoz fordulsz, akkor akár el is mehetsz vacsorázni közben (ahogyan láttad is).
Azért nem reménytelen a helyzet, de mindenképpen létre kell hoznod valami gyorsítótárat a memóriában, különben használhatatlan lesz a programod. Arra gondoltam, hogy először is definiálsz egy struktúrát, mondjuk egy rekordot, amiben a tulajdonságfa egy csomópontjának adatai teljesen beleférnek (olyasmi lesz ez, mint egy adatbázisrekord). Az első select alapján beállítod a RootNodeCount tulajdonságot, erre elkezdenek áramlani az OnInitNode események. Ezekben a gyökérelemeknél nem csinálsz mást, csak megjegyzed, hogy melyik eredménysorhoz melyik node tartozik, és beállítod, hogy van neki gyermeke, valahogy így:
[CODE]
procedure TLaoCeForm.VSTInitNode(...);
var Data: TLaoCeNodeData;
begin
if ParentNode = nil // ezek a root node-ok
then
InitialStates := InitialStates + [ivsHasChildren]
else begin // ezek meg a subselectek-hez tartozó node-ok lesznek
Data := Sender.GetNodeData(Node);
{itt kitöltöd a cuccaiddal az adatstruktúrát}
end;
end;
[/CODE]
Ezek után az a lényeg, hogy az OnInitChildren eseménykezelőben lefuttathatsz egy-egy subselect-et az aktuális node-hoz eltárolt paraméter alapján, és beállíthatod, hogy hány eredménysora van (erre megint beindulnak az OnInitNode-ok, de már a gyermekelemekre), a többit meg elintézed a fenti OnInitNode eseménykezelőben. Az általam TLaoCeNodeData-nak nevezett struktúrát tehát jól találd ki.
Ezzel a megoldással megúszod a teljes adatbázis letárolását a memóriában, de a jó teljesítményhez annyit muszáj megtenned, hogy a képernyőn látható (a megnyitott node-okhoz tartozó) adatok a memóriában legyenek.
Bedobhatsz egy olyan trükköt is, hogy egyszerre csak egy root node-ot lehessen lenyitni, a második lenyitásakor a korábban már lenyitottat felcsukod, így a hozzá tartozó gyermekelemeknek a memóriáját (TLaoCeNodeData csomagjait) klasszul újra felhasználhatod az aktuálisan lenyitott node-hoz.
Végső soron tény, hogy nem kifejezetten DataSet típusú működéshez találták ki ezt a komponenst - de annál szebb a kihívás, nemde? :)
(Ha nagyon sz**sz vele, tudok küldeni kisebb példakódokat, de szerintem ez alapján már minden OK lesz.) -
Alan
aktív tag
Ha a Mike Lischke-féle Virtual Treeview-ra gondolsz (a bonyolultság miatt úgy sejtem, ez lehet az), akkor szerencséd van, csináltam már vele programokat. Mit akarsz tudni?
Alapvetően virtuális komponens, tehát az a működés lényege, hogy megmondod neki, hány sora legyen, majd a cellák tartalmát magadnak kell feltölteni egy-egy esemény meghívódásakor (feltéve, hogy adatrács céljára kell). Persze inkább nem untatlak ilyenekkel, biztos komplexebb kérdéseid vannak :) -
Alan
aktív tag
Nem, a memóriakezelés ebből a szempontból teljesen más, mint a folyamat- meg szálkezelés és általános válaszok itt nagyon ritkán adhatók pontatlanul megfogalmazott kérdésekre. Szerintem ha tényleg érdekel, olvass ennek utána az msdn.microsoft.com-on, ott rengeteg hasznos cikket találsz.
A legjobb forrás emellett az Inside Windows 2000 c. könyv Mark Russinovich és Dave Solomon tollából. Igazi guruk ők, volt szerencsém találkozni is velük, és a könyvben nulla a marketing, csak hasznos és színvonalas, mélyszintű infók vannak. A rossz hír, hogy negyven-ötven dolcsiba kerül (viszont van hozzá CD, rajta egy halom kernel-hackelő segédeszközzel).
Igazi operációs rendszernek a Windows NT/2000/XP/2003 tekinthető, a 95/98/ME sajnos csak kísérletezgetés volt a Microsoft részéről. Természetes, hogy lefagynak benne a (rossz) programok, és sajnos az is, hogy magukkal rántják a rendszert, mert ott a kernel memóriaterülete nincs (teljesen) védve a programoktól.
Az NT-alapú rendszereket egyetlen módon, rossz (vagy rosszindulatú) eszközmeghajtókkal, vagyis driverekkel lehet ''kék halálba'' rántani (ezt a problémát viszont egyelőre nem lehet elvben sem kikerülni - ha az eszközmeghajtókat sem engedjük a hardverhez nyúlni, vagy nem engedjük, hogy a kernel címterében is dolgozzanak, azt a teljesítmény nagyon megsínyli).
Persze néha előfordul, hogy találnak emellett egy-egy kernelhibát, ami miatt szintén elkékül a képernyő, de ez nagyon ritka és általában csak extrém körülmények között fordul elő. A biztonsági problémák nem tartoznak ide, az sajnos egy egész más asztal. -
Alan
aktív tag
válasz
Auslander
#62
üzenetére
Gratulálok, Ausländer, és örülök, hogy ilyen klassz munkád van! Meg annak is, hogy Delphiben csinálod, bár ez szigorúan magánvélemény (remélem, nem jön el az az idő, amikor már csak Visual Studio X meg Visual Studio Y közül lehet választani) :) Sok sikert meg további érdekes munkákat kívánok Neked!
-
Alan
aktív tag
Nem olyan irgalmatlanul sok az.
Egyrészt ha a Task Manager-ben a Processes fülön a Mem Usage oszlopot nézed, észrevehető, hogy bár külön-külön nem annyira vészesek a memóruiafoglalások, a sok kicsi végül sokra megy. Másrészt pedig mivel a memória egy részének a lapozófájlban foglal helyet, nem annyira veszélyes a helyzet, mint azt a ''nagy zöld csík'' a Performance fülön sejtetné. Harmadrészt pedig egy csomó dolgot gyorsítótáraz a memóriában, azért is fogy látszólag gyorsan a fizikai memória (Performance fül, Physical Memory csoport, Total és Available mezők) - ha viszont másnak szüksége van ezekre a területekre, akkor simán megkaphatja, elég, ha viszonylag rövid időre viszonylag magas laphibagyakoriságot produkál.
Nagyon érdekes egyébként, hogy a programok (futtatható fájlok) betöltése is így, ''belaphibázással'' történik, tulajdonképpen be sem tölt semmit a rendszer, hanem foglal a programnak egy kis virtuális memóriát a minimális munkakészlettel, elindítja a programot, aztán a többit rábízza a memóriakezelőre. Ha jön befelé a tizenegy megás winword.exe, előbb-utóbb a kis munkakészlet miatt tömegesen fog laphibázni (inkább előbb...), és akkor úgyis kap majd még memóriát. Végül pont annyi fizikai memóriát foglal majd el, amennyi ténylegesen kell neki az induláshoz - tehát szinte biztos, hogy jobban jár a felhasználó, mintha az elején automatikusan lefoglalta volna a Windows mind a tizenegy megát a fizikai memóriából és betöltötte volna az egészet, majd aztán később lapozgatná kifelé a nem kellő darabokat.
''Lustaság fél egészség'', ez a loader mottója :) -
Alan
aktív tag
válasz
Auslander
#57
üzenetére
Csatlakozom, habár én azért hozzávenném a Digital Alpha processzorait is, míg ki nem nyírták őket.
Így van, az Alpha processzorok előtt is fejet hajtunk. Csodálatos sorozat volt, remek teljesítménnyel és gyönyörű architektúrával, én is sajnálom, hogy véget vetettek neki.
1. Ha én adom vissza, akkor új memória foglalásakor ezt igy érintetlenül nem kaphatom vissza. Ebben az esetben elvár(ha)tom, hogy nullázva legyen.
Ha te szabadítasz fel egy memóriaterületet és megint te kapod vissza, akkor szerintem előfordulhat, hogy optimalizál és nem nullázza ki, hanem már a szabad lapok listájáról kiadja. De ezen nem fogunk összeveszni :)
És amit igazából akartál kérdezni, arra sajnos csak azt tudom mondani, hogy namespace extension-ök írásában abszolút amatőr vagyok, de a [L]http://www.whirlingdervishes.com/nselib/[/L] oldalon láttam egy jónak tűnő keretrendszert, ami alapján legalábbis feltételezem, hogy protokoll típusú NE-re is van driver nélküli megoldás. Sajnos ebben más kell, hogy segítsen neked.
<off>
Amúgy Németországban fejlesztesz, ezért lettél ''külföldi''? Miben dolgozol, meg milyen projekteken (ha itt is érdekes és elmondható)?
</off> -
Alan
aktív tag
válasz
Auslander
#53
üzenetére
Szia Ausländer! Köszi szépen az elismerést :)
Hát persze, nyilvánvaló, hogy szinte semmit sem az ujjukból szopnak a fejlesztők, mindennek van előzménye. A VMS-t én annyira nem ismerem, bár azt az egyet tudtam, hogy a munkakészlet onnan ''származott át''.
Nem vagyok biztos benne, hogy a flat modell előnyösebb lenne a szegmentáltnál. Utóbbinál pl. viszonylag egyszerűen lehetne memóriamegosztást biztosítani két process között. Ez flat modellnél nem egyszerű. (jojo, használhatom a kernel memory space-et, de ez nem szép))
Ízlések és pofonok, szerintem kifejezetten jópofa megoldás, hogy ha kernel vagy, minden folyamat címterében ugyanott találod a cuccaidat :)
Memóriamegosztáshoz nem is kell a kernel címtere, erre ott vannak a prototípus-laptáblabejegyzések, amikkel hatékonyan, 4K-nként lehet megosztani a memóriát.
Én egyébként korábban Motorola processzorokat programoztam, és a szegmentálástól a mai napig kiráz a hideg... A szegmentálás és a lapozás együttes használatánál valószínűleg sokkal lassabb lenne a címleképzés TLB miss esetén, de egyéb más okát nem tudom, miért nem használja a Windows (sem). De ennek speciel örülök, sosem firtattam mélyebben a dolgot :).
Hogy kell Non Pagable memóriát allokálni Windowsban? És lehet-e kérni, hogy ez ki legyen már nullázva? VMS alatt ez működött. Erős a gyanúm, hogy Windows alatt is mennie kell valahogyan. Jó lenne, ha nem nekem kellene ezzel foglalkozni. A rendszernek van elég ideje, hogy nullázgassa a lapokat.
VirtualAlloc() vagy VirtualAllocEx(), majd VirtualLock(). Az egy folyamatnak biztosított non-paged pool alapértelmezésben nagyon kicsi (~30 lap), ezzel a fajta foglalással vigyázni kell, nem biztos, hogy sikerül. Mihez kell neked nem lapozható memória? Drivert írsz?
Egyébként mindig kinullázott memóriát kapsz, bármit is csinálsz (ez C2-es biztonsági követelmény), kivéve, ha saját magad által korábban használt lapot kapsz vissza, az nem biztos, hogy ki lesz nullázva (de ez nem is biztonsági rés).
Az Intel adottságai miatt ez lehetne akár 4MB-os page is. No jó, csak a 386-osoktól kezdődően
Hm, élvezetes is lenne végigülni egy-két egészséges belapozást 4 megás lapoknál :D Egyébként AMD Athlonnál lehet 2MB-os lapokat is kérni, de ez a gyakorlat tudtommal nem nagyon terjedt el. Tudom, a Windowsnál lehet kérni, hogy a kernel egy részét tegye 1 db nem lapozható 4 MB-os lapra, fejből már nem emlékszem, hogyan, de a registry-ben külön kézzel kell beállítani. A SlotA Athlonok ezen a téren pont hibásak voltak és ezt nem volt szabad rajtuk bekapcsolni, különben jött a kék halál.
Ja, és annak idején a Motorola 68030-nál 0,5 és 32 KB között lehetett állítani a lapméretet.
Tíz másodperces néma főhajtás a Motorola 680x0 sorozat emlékére. A legjobb processzorok voltak.
Az e-mail címemre küldhetsz kérdést, persze, de jobban örülnék, ha itt a fórumon megbeszélnénk az érdekesebbeket. -
Alan
aktív tag
biztos bena kerdes, de mit jelent pontosabban az, hogy a program tenylegesen hozzafer (hasznalatba veszi) az adott teruletet a gyakorlatban?
Azt, hogy olvas róla vagy ráír. Egy elvi pszeudokóddal illusztrálva,
ptr = malloc(8192); <= foglalás (allocation, 8K)
ptr++; <= nem történik semmi
ptr[30] = 0x64; <= első lap kommitálása (commit, 4K)
ptr += 5000; <= nem történik semmi
ptr[50] = 0x80; <= második lap kommitálása (commit, 4K)
ha atszinezem egy pixelet pirosrol zoldre az mar hasznalata az egesz kepnek vagy ez is 4k-s blokkonkent ertendo es csak azt a kis reszt vettem hasznalatba?
Az előző példából is láthatod, hogy laponként történik a tényleges használatba vétel.
A teljes igazság egyébként, hogy egy-egy lap utólagos kommitálásakor (tehát belapozáskor, ha már korábban bent volt a lap, csak valamiért, pl. a munkakészlet maximumának elérése miatt ezután valamikor a Windows kilapozta) nem egyesével hozza vissza a kért lapokat, hanem előreolvas 4-5 lapot és ''mögéolvas'' 2-t.
Magyarán ha Te az n. lapra hivatkozol és nincs bent a fizikai memóriában, akkor az n-2, n-1, n, n+1...n+5 lapokat mind behozza egy ''lökettel''. Hogy miért, azt biztosan könnyedén kitalálod :)
bizonyos almodozasaimban (programozasos - tudod, a 'ha lenne idom meg penzem' kezdetuek) szo van arrol hogy hatalmas true/high color kepet hasznalnek bizonyos nem kepi informaciok letarolasahoz.
Arar gondolsz, hogy a legkisebb helyiértékű biteket elrontod (mert úgysem látszik), és oda bevarrod az információkat? Jó kis trükk :), tudom, van valami neve is, valamilyen 'gráfia lesz ez is.
Ismerem ezeket az álmodozásokat, nálam halomban állnak a félkész freeware projektek... de azért egy szép napon, ha jön egy jóságos szponzor, mindet befejezem :) -
Alan
aktív tag
Köszi, kedves tőled :)
A válaszok:
- te ezt tanitod valahol?
- Igen, de inkognitómat nem fedhetem fel csak úgy :)
- a woking set-et lehet latni a task managerben (a kozepso oldalon a processeknel)?
- Igen. Próbáld ki, hogy megnézed egy program munkakészletét, aztán leminimalizálod. Rögtön leugrik 1-2000 K-ra a munkakészlete, ha nem kevesebbre. Másik jópofa kísérlet: ha már úgyis Delphiben programozol, tölts be egy nagyobb projektet, fordítsd le, nyisd meg az összes formját, majd nézd meg a munkakészletet. Minimalizáld a Delphi-t. Nyiss meg egy csomó másik izmos programot (pl. Photoshop), működj bennük, hadd teljen a fizikai memória. Most pedig állítsd vissza a Delphi-t normál méretre. Két dolog történik: egyrészt a munkakészlete nem áll vissza teljesen (ezt már az eddigiek alapján is sejtettük), másrészt jó sokáig bevilágítja a szobát a merevlemez piros LED-je és szemmel láthatóan lassan rajzolódnak ki a Delphi ablakai. Miért? Mert közben a tevékenység hiánya miatt laphibákat sem nagyon generált, ezért a Windows fokozatosan elvette tőle majdnem az összes fizikai memóriát, így visszaállításkor a lapozófájlból jön vissza mind a 40-100 megabyte, amit addig elfoglalt.
- working set ujra: ''Ennek a méretét a rendszer maga szabályozza'' ez azt jelenti hogy novelheti es csokkentheti is, mivel szabalyozni probalja a page faultok masodpercenkenti szamat, ugye?
- Igen, pontosan így van. Azért van egy abszolút minimum, ami alá sosem viszi le, nehogy baj legyen, de ez csak pár száz KB. És természetesen van abszolút maximum is, a kettő között azonban elég nagy a Windows játéktere. -
Alan
aktív tag
Lao ce, hát nekem is öröm, ha normális emberekkel társaloghatok, ráadásul egyre ritkábban adatik meg ez egy fórumon.
A Delphi telepítésénél meg lehet(ett) adni, hogy kéred-e a Win32 API súgóját, és ha kérted, akkor a Start -> (All) Programs -> Borland Delphi 6 -> Help -> MS SDK Help Files menüben találod az összes hozzá tartozó fájlt. Amire valószínűleg gondolsz, az a Win32 Programmer's Reference (win32.hlp), vigyázz, sok hasonló nevű van.
A délelőtt ma elég borongós, aludni nem sokat sikerült, úgy hogy minden feltétel adott egy jó kis Windows eszmefuttatáshoz :) ). -
Alan
aktív tag
Van egy jó kis ingyenes szoftver, MemProof a neve, a [L]http://www.automatedqa.com/downloads/memproof.asp[/L] címről letöltheted. Nagyon szigorú, biztos megtalálod majd vele a szivárgást (debug infóval fordítsd a programot, különben nem tudja követni az erőforrásokat).
A másik részére elég hosszú a válasz, ugye nem haragszol meg, ha most éjjel nem pötyögök be sok ezer karaktert :) Igazad van egyébként, minimalizálásnál a Windows automatikusan nagymértékben lecsökkenti az adott program munkakészletét, feltételezve, hogy a minimalizált programmal nem fogsz interakciót kezdeményezni. Amikor pedig visszaveszed a programot normál méretre, nem kapja automatikusan vissza a korábbi mennyiségű memóriát, csak egy részét, ha szüksége van rá, ''visszafaultolja'' magának, tehát laphibákat fog okozni és ennek hatására kapja vissza a fizikai memóriát fokozatosan. Ha tényleg érdekel, szólj és akkor később leírom, miért meg hogy van mindez :) -
Alan
aktív tag
Annyit egyébként még megtehetsz a Task Manager-ben is, hogy a Performance fülön a Commit Charge csoportban a Total mezőt figyeled, bár ez nem tökéletes, mert a teljes rendszerre vonatkozó aktuális virtuálismemória-foglalást írja ki (amiben nemcsak a Te programod változásai lesznek benne), de ha elég nagy blokkokat foglalsz és szabadítasz fel, akkor itt láthatod, hogy ''ugrál'' a memóriafoglalás, ha nem is pont annyival, amennyit Te foglalsz vagy felszabadítasz.
-
Alan
aktív tag
Sajnos a Windows memóriakezelése jóval bonyolultabb annál, hogy alloc/release és rögtön visszanövekszik a szabad memória.
Röviden legyen elég annyi, hogy a Task Manager-ben sehol nem láthatod, hogy a Te programod konkrétan mekkora részt foglalt le a saját 2GB-os virtuális címteréből (mert Te erre lennél kíváncsi, itt szabadul fel a FreeAndNil(WorkBitmap) után a virtuális memória). Csak a program munkakészletét, azaz a neki adott fizikai memória méretét látod, amit viszont a Windows maga szabályoz.
Egyébként egyszerű ''memory leak debugging'' kiválóan megvalósítható úgy is, hogy a Delphi-t a -hm paraméterrel indítod, így a címsorban folyamatosan frissített memóriainformációk lesznek az éppen futtatott programodra is (persze csak ha F9-cel futtatod). -
#25
Alan
aktív tag
CsendPenge
#24
Alan
aktív tag
válasz
CsendPenge
#24
üzenetére
Félreértesz. Csak a fejlesztőrendszerhez kell NT alapú operációs rendszer, a ''késztermék'' már utána elmegy bármin (persze ha memóriát szivárogtatnak a fejlesztők, akkor nyilván nem :))
A fejlesztéshez iszonyúan sok Windows resource kell általában, hiszen a fejlesztőrendszer betöltése után az éppen fejlesztett programhoz általában nyitva tart az ember legalább 20-25 ablakot, sokszor az összes formot, néha több nyelvű változatban, rajtuk az összes komponenssel, vezérlővel és kezelőszervvel... nem is beszélve arról, ha munka közben hibás verziók születnek, amik trutymót hagynak maguk után a memóriában (természetes velejárója a munkának).
Szóval programozás közben hamar elfogy az a pár ezer ablakkezelő Windows 9x alatt, erre gondoltam. -
#22
Alan
aktív tag
CsendPenge
#20
Alan
aktív tag
válasz
CsendPenge
#20
üzenetére
Igen, az 1. eset is könnyen elképzelhető. De még ha nincs is semmi hiba, a Windows 9x előbb-utóbb úgyis probléma lesz.
Ha viszont NT alapú rendszeren fejleszt a topicindító, akkor nagyon valószínű, hogy fején találtad a szöget. -
-
Alan
aktív tag
...az eredeti felvetésre pedig valószínűleg az a válasz, hogy Windows 9x rendszert nem érdemes fejlesztésre használni, mert fixen rögzített benne bizonyos erőforrások (pl. ablakkezelők) maximális száma, függetlenül a memória méretétől. (És a Windows-nál szinte *minden* ablak: a gomb, a kép, a menü, a menüpont, az ikon, az eszközsor, a panel stb.) Ezért mindegy, mennyi RAM-ot vesz az ember, a Windows 9x úgyis beakaszt.
Aktív témák
- Dell Precision 7760 Tervező Vágó Laptop -70% 17,3" i7-11850H 32/512GB NVIDIA A3000 6GB FHD
- Lenovo ThinkPad P16v G2 Mobil Munkaállomás -50% Ultra 7 165H 32/1TB RTX 2000 8GB 19Hó Gari
- Bontatlan! Új Lenovo Thinkpad T14 G5 Tartós Üzleti Laptop 14" -45% Ultra 7 165U 16/512 FHD+ Magyar!
- Samsung Galaxy A16 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bontatlan Kingston 32GB (16GBx2) DDR4 3200MHz KCP432ND8/16 (Beszámítás)
- Újszerű iPhone 14 Plus 128GB Lila független, 100% aksi, 1 ÉV GARANCIA, 14 Napos elállás!
- -75% Dell XPS 13 (9320) i7-1260P 16GB Ram/1TB SSD FHD+ Gari
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
- Honor X8 128GB, Kártyafüggetlen, 1 Év Garanciával
- Beszámítás! Acer Predator Helios Neo 16 notebook-i9 14900HX 16GB DDR5 1TB SSD RTX 4060 8GB W11
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest