Aktív témák
-
rdi
veterán
Na én se ma programoztam utóljára, lehet, hogy nem is értek hozzá, de a memória felszabadítása nem azt jelentené, hogy onnantól írhat rá bármelyik progi?
Vagyis a felszabadítással bennmarad a memóriaszemét??
Tehát ahhoz, hogy szabadnak lássék, kellene egy memóri resetelő program?Fej! Tor! Potroh!
-
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). -
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
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
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
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
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 :) -
Auslander
tag
Szia,
...csak az erdekesseg kedveert ossze kellene vetni mas oprendszerek megoldasaval...
Rendben, igaz én csak egyhez tudom hasonlítani, és ez a VMS/OpenVMS. Mivel a Windows NT fejlesztésében (leginkabb kernel) anno a DEC-től elcsábított/megvett fejlesztőmérnökök igen erős szerepet játszottak, ezért igen nagyfokú hasonlóság fedezhető fel a két rendszer memória/task kezelésében. A terminológia is közel azonos mindkét rendszer esetén. Azonos elvek a working-set-eknél, minkét rendszer pagefile.sys-nek hívja a lapozófájlt; a process által visszajuttatott memória a VMS-ben is először egy listára kerül, amit a processz visszakap, ha kell neki, ha még nem került vissza a rendszer listára, stb. Mindkét oprendszer flat-model-t használ. (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)). Azt, hogy most a VMS, vagy a Windows verzió a jobb azt nem tudhatom már, mivel a VMS-ről több mindent már nem tudok, mióta a Compaq(bérenc) megvette a Digitált. Brrrrrrrr.
Alan
Ha már így összefutottunk...
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.
...Intel hardver adottságai miatt 4KB-os blokkokban intézi a virtuálismemória-foglalásokat...
Az Intel adottságai miatt ez lehetne akár 4MB-os page is. No jó, csak a 386-osoktól kezdődően :)
Egyébként tetszik amit írsz. Tömör, lényegretörő, érthető.
Ha lenne Windows-al kapcsolatos kérdésem, azt a megadott e-mail címedre küldhetem?
Üdv:
AusländerA kígyó és a zsiráf közt nem csak az a különbség, hogy az egyik vízszintesen, a másik függőlegesen hosszú....
-
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
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
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
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. -
lao ce
aktív tag
megprobalom nagyjabol leirni mi van a programban.
az initnode-ban:
if ParentNode = nil then
begin
...mastertabla feltoltese recordsetbol
...InitialStates := InitialStates + [ivsHasChildren, ivsExpanded];
...MasterDataSet.next;
end;
InitChildren:
MyMasterRec := PMyMasterRec( VST.GetNodeData(Node));
recordset selectje (ID alapjan)
ChildCount := DetailDataSet.RecordCount;
if DetailDataSet.RecordCount > 0 then
begin
...while not(DetailDataSet.Eof) do
...begin
......feltoltese a Detail record tomb mezoinek feltoltese [i]
......inc(i);
...end;
end;
a feltoltesnel ki is irom egy memoba, es ugy nez ki, hogy minden adat szepen a helyen van, szoval szerintem a kovetkezokben lesz az ami nem mukodik (mar hogyha nem az egesz ugy ahogy van hasznalhatatlan)
GetText:
if TextType = ttNormal then
begin
...case Column of
...0:
......if Node.Parent = Sender.RootNode then
......begin
.........MyMastRec := Sender.GetNodeData(Node);
.........Text := MyMastRec.NameCol;
......end
......else
......begin
.........MyMastRec := Sender.GetNodeData(Node);
.........Text := MyMastRec.MyDetRec[Node.Index].FirstColumnToWrite;
......end;
stb
nomost, ez mar nem akar mukodni. a Node.Parent = Sender.RootNode reszen megkapom a kivan ertekeket, de a detail recordnal ures minden.nicht kompot
-
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
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
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
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);
Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest