Când scrieți aplicații de lungă durată - genul de programe care vor petrece cea mai mare parte a zilei minimizate în bara de activități sau zona de notificare, poate deveni important să nu lăsați programul să fugă cu utilizarea memoriei.
Cele două coloane din dreapta indică utilizarea procesorului (timpului) și utilizarea memoriei. Dacă un proces are un impact grav asupra oricăruia dintre acestea, sistemul dvs. va încetini.
Genul de lucruri care afectează frecvent utilizarea procesorului este un program în buclă (cereți oricărui programator care a uitat să pună o declarație „citește următorul” într-o buclă de procesare a fișierelor). Aceste tipuri de probleme sunt de obicei destul de ușor de corectat.
În schimb, utilizarea memoriei nu este întotdeauna aparentă și trebuie gestionată mai mult decât corectată. Presupunem, de exemplu, că se execută un program de tip captură.
Acest program este folosit chiar pe parcursul zilei, posibil pentru captarea telefonică la un birou de asistență sau din alte motive. Pur și simplu nu are sens să îl închideți la fiecare douăzeci de minute și apoi să îl porniți din nou. Va fi folosit pe parcursul zilei, deși la intervale rare.
Dacă programul se bazează pe unele prelucrări interne grele sau are o mulțime de lucrări de artă pe formele sale, mai devreme sau mai târziu folosirea memoriei va crește, lăsând mai puțină memorie pentru alte procese mai frecvente, împingând în sus activitatea de paging și, în cele din urmă, încetinirea computerului.
Să spunem că veți proiecta un program cu formularul principal și două forme suplimentare (modale). De obicei, în funcție de versiunea dvs. Delphi, Delphi va insera formularele în unitate de proiect (Fișier DPR) și va include o linie pentru a crea toate formularele la pornirea aplicației (Aplicație. CreateForm (...)
Liniile incluse în unitatea de proiect sunt proiectate de Delphi și sunt ideale pentru persoanele care nu sunt familiarizate cu Delphi sau încep să o folosească. Este convenabil și util. Înseamnă, de asemenea, că TOATE formularele vor fi create la pornirea programului și NU la nevoie.
În funcție de ce este proiectul dvs. și de funcționalitatea pe care ați implementat-o, un formular poate utiliza foarte multă memorie formele (sau în general: obiectele) ar trebui create numai atunci când este nevoie și distruse (eliberate) imediat ce nu mai sunt necesar.
Ambele, „DialogForm” și „OccasionalForm” trebuie eliminate din lista „Formulare de creare automată” și mutate în lista „Formulare disponibile”.
Vă rugăm să rețineți că strategia prezentată aici se bazează pe presupunerea că programul în cauză este un program de tip „captare” în timp real. Poate fi însă adaptat cu ușurință pentru procesele de tip lot.
Delphi a încercat să minimalizeze acest lucru și are o arhitectură proprie de gestionare a memoriei, care folosește blocuri mult mai mici, dar aceasta este practic inutil în mediul Windows deoarece alocarea memoriei revine în cele din urmă sistemului de operare.
După ce Windows a alocat un bloc de memorie unui proces, iar acest proces eliberează 99,9% din memorie, Windows va percepe în continuare întregul bloc care va fi folosit, chiar dacă este de fapt un singur octet al blocului folosit. Vestea bună este că Windows oferă un mecanism de curățare a acestei probleme. Shell-ul ne oferă o API numită SetProcessWorkingSetSize. Iată semnătura:
Prin definiție, funcția SetProcessWorkingSetSize stabilește dimensiunile de lucru minime și maxime pentru procesul specificat.
Această API este destinată să permită o setare la nivel scăzut a limitelor minime și maxime de memorie pentru spațiul de utilizare a memoriei procesului. Cu toate acestea, are un mic ciudat încorporat în ea, care este cel mai norocos.
Dacă valorile minime și maxime sunt setate la $ FFFFFFFF, atunci API-ul va tăia temporar dimensiunea setată la 0, schimbând-o din memorie și imediat ca aceasta revine în memoria RAM, va avea cantitatea minimă de memorie care îi este alocată (acest lucru se întâmplă în câteva nanosecunde, deci pentru utilizator ar trebui să fie imperceptibil).
O apelare la această API va fi făcută doar la intervale date - nu continuu, deci nu ar trebui să existe niciun impact asupra performanței.
Acum, verificați periodic ultimul număr de bifare în raport cu „Acum” și dacă diferența dintre cele două este mai mare decât perioada considerată a fi o perioadă de repaus sigură, decupați memoria.
Acum decideți după ce perioadă de timp veți considera programul inactiv. Am decis două minute în cazul meu, dar puteți alege orice perioadă doriți în funcție de circumstanțe.
Adaptarea acestei metode pentru perioade lungi de procesare sau procese de lot este destul de simplă. În mod normal, veți avea o idee bună unde va începe un proces îndelungat (de exemplu, începutul unei citiri a buclelor prin milioane de înregistrări ale bazei de date) și unde se va încheia (sfârșitul buclei de citire a bazei de date).
Pur și simplu dezactivează-ți cronometrul la începutul procesului și activează-l din nou la sfârșitul procesului.