Når du skriver applikationer, der har længe kørt - den form for programmer, der vil tilbringe det meste af dagen minimeret til proceslinjen eller System bakke, kan det blive vigtigt ikke at lade programmet "løbe væk" med hukommelsesforbrug.
De to højre kolonner viser CPU- (tids-) brug og hukommelsesforbrug. Hvis en proces påvirker en af disse alvorligt, vil dit system bremse.
Den slags ting, der ofte påvirker CPU-brugen, er et program, der loopes (spørg enhver programmør, der har glemt at placere en "læst næste" -sætning i en filbehandlingssløjfe). Disse slags problemer korrigeres normalt ret let.
Hukommelsesforbrug er derimod ikke altid synlig og skal styres mere end korrigeres. Antag for eksempel, at et program til fangsttype kører.
Dette program bruges hele dagen, muligvis til telefonisk optagelse ved en helpdesk eller af en eller anden grund. Det giver bare ingen mening at lukke den ned hvert 20. minut og derefter starte den op igen. Det vil blive brugt hele dagen, skønt i sjældne intervaller.
Hvis dette program er afhængig af nogen tung intern forarbejdning eller har masser af illustrationer på dens former, før eller senere dets hukommelsesforbrug vil vokse og efterlade mindre hukommelse til andre hyppigere processer, skubbe op til sideaktiviteten og i sidste ende bremse computeren.
Lad os sige, at du vil designe et program med hovedformularen og to yderligere (modale) formularer. Afhængigt af din Delphi-version vil Delphi typisk indsætte formularerne i projekt enhed (DPR-fil) og vil omfatte en linje til at oprette alle formularer ved applikationsstart (Application. CreateForm (...)
Linjerne, der er inkluderet i projektenheden, er af Delphi-design og er fremragende til folk, der ikke er bekendt med Delphi, eller som lige er begyndt at bruge det. Det er praktisk og nyttigt. Det betyder også, at ALLE formularerne vil blive oprettet, når programmet starter, og IKKE, når det er nødvendigt.
Afhængig af hvad dit projekt handler om, og den funktionalitet, du har implementeret en form, kan du bruge en masse hukommelse formularer (eller generelt: objekter) skal kun oprettes, når det er nødvendigt og ødelagt (frigivet), så snart de ikke længere er nødvendig.
Både "DialogForm" og "OccasionalForm" skal fjernes fra listen over "Auto-create forms" og flyttes til listen "Available Forms".
Bemærk, at den her beskrevne strategi er baseret på antagelsen om, at det pågældende program er et program i realtid “capture”. Det kan dog let tilpasses til batch-type processer.
Delphi har forsøgt at minimere dette og har sin egen hukommelsesadministrationsarkitektur, der bruger meget mindre blokke, men det er det næsten ubrugelig i Windows-miljøet, fordi hukommelsestildelingen i sidste ende hviler på operativsystemet.
Når Windows har tildelt en blok hukommelse til en proces, og denne proces frigør 99,9% af hukommelsen, Windows oplever stadig, at hele blokken er i brug, selvom kun en byte af blokken faktisk er i brug Brugt. Den gode nyhed er, at Windows leverer en mekanisme til at rydde op i dette problem. Skallen giver os et API kaldet SetProcessWorkingSetSize. Her er underskriften:
Per definition indstiller funktionen SetProcessWorkingSetSize minimum og maksimal arbejdsindstilling for den specificerede proces.
Denne API er beregnet til at tillade en lav indstilling af minimum og maksimal hukommelsesgrænser for processens hukommelsesbrugsareal. Det har dog et lille skænderi indbygget i det, der er mest heldig.
Hvis både minimums- og maksimumværdierne er indstillet til $ FFFFFFFF, vil API'en midlertidigt trimme den indstillede størrelse til 0, bytte den ud af hukommelsen og straks som den springer tilbage til RAM, det vil have den blotte minimum mængde hukommelse, der er allokeret til det (alt dette sker inden for et par nanosekunder, så for brugeren skal det være umærkelig).
Et opkald til denne API foretages kun med givne intervaller - ikke kontinuerligt, så der bør slet ikke være nogen indflydelse på ydelsen.
Kontroller nu regelmæssigt det sidste antal kryds ved "Nu", og hvis forskellen mellem de to er større end den periode, der anses for at være en sikker tomgangsperiode, skal du trimme hukommelsen.
Bestem nu efter hvilket tidsrum, du vil betragte programmet som inaktivt. Vi besluttede to minutter i mit tilfælde, men du kan vælge en hvilken som helst periode, du vil, afhængigt af omstændighederne.
At tilpasse denne metode til lange behandlingstider eller batchprocesser er ganske enkelt. Normalt har du en god idé, hvor en langvarig proces starter (f.eks. Begyndelsen af en læsning gennem millioner af databaseposter), og hvor den slutter (slutningen af databaselæsesløjfen).
Du skal blot deaktivere timeren i starten af processen og aktivere den igen ved afslutningen af processen.