Når du skriver applikasjoner som kjører lenge - den typen programmer som vil tilbringe mesteparten av dagen minimalt til oppgavelinjen eller oppgavelinje, kan det bli viktig å ikke la programmet "stikke av" med minnebruk.
De to høyre kolonnene indikerer CPU (tids) bruk og minnebruk. Hvis en prosess påvirker en av disse alvorlig, vil systemet bremse.
Den typen ting som ofte påvirker CPU-bruken, er et program som sløyfer (spør hvilken som helst programmerer som har glemt å legge en "lese neste" -uttalelse i en filbehandlingssløyfe). Slike problemer blir vanligvis ganske enkelt rettet.
Minnebruk er derimot ikke alltid tydelig og må styres mer enn korrigert. Anta for eksempel at et program for fangsttype kjører.
Dette programmet brukes hele dagen, muligens til telefonfangst ved en helpdesk, eller av en eller annen grunn. Det er bare ikke fornuftig å slå den av hvert tjue minutt og så starte det opp igjen. Det vil bli brukt hele dagen, selv om det i sjeldne intervaller.
Hvis det programmet er avhengig av tung intern prosessering eller har mange kunstverk på formene, før eller siden
minnebruk kommer til å vokse, og etterlater mindre minne for andre hyppigere prosesser, presser opp sideaktiviteten og til slutt bremser datamaskinen.La oss si at du kommer til å designe et program med hovedskjema og to ekstra (modale) skjemaer. Avhengig av din Delphi-versjon, vil Delphi vanligvis sette skjemaene inn i prosjektenhet (DPR-fil) og vil inneholde en linje for å opprette alle skjemaer ved oppstart av applikasjonen (Application. CreateForm (...)
Linjene som er inkludert i prosjektenheten er av Delphi design og passer bra for folk som ikke er kjent med Delphi eller akkurat begynner å bruke den. Det er praktisk og nyttig. Det betyr også at ALLE skjemaene skal opprettes når programmet starter opp og IKKE når det trengs.
Avhengig av hva prosjektet ditt handler om og funksjonaliteten du har implementert et skjema, kan du bruke mye minne skjemaer (eller generelt: objekter) skal bare opprettes når det trengs og ødelegges (frigjøres) så snart de ikke lenger er nødvendig.
Både "DialogForm" og "OccasionalForm" må fjernes fra listen over "Auto-create forms" og flyttes til "Available Forms" -listen.
Vær oppmerksom på at strategien som er skissert her er basert på antagelsen om at det aktuelle programmet er et sanntids “capture” -program. Det kan imidlertid lett tilpasses for batch-prosesser.
Delphi har prøvd å minimere dette og har sin egen minnehåndteringsarkitektur som bruker mye mindre blokker, men dette er det praktisk talt ubrukelig i Windows-miljøet fordi minnetildelingen til slutt hviler på operativsystemet.
Når Windows har tildelt en blokk med minne til en prosess, og den prosessen frigjør 99,9% av minnet, Windows vil fremdeles oppfatte at hele blokken er i bruk, selv om det bare er en byte av blokken brukt. Den gode nyheten er at Windows gir en mekanisme for å rydde opp i dette problemet. Skallet gir oss et API som heter SetProcessWorkingSetSize. Her er signaturen:
Som definisjon setter SetProcessWorkingSetSize-funksjonen minimum og maksimal arbeidsstørrelse for den spesifiserte prosessen.
Denne APIen er ment å tillate et lavt nivå innstilling av minimums- og maksimale minnegrenser for prosessens minnebruksplass. Det har imidlertid et lite sære innebygd i det som er mest heldig.
Hvis både minimums- og maksimumsverdiene er satt til $ FFFFFFFF, vil APIen trimme den angitte størrelsen midlertidig til 0, bytte den ut av minnet og straks som den spretter tilbake til RAM, den vil ha den minste minimumsmengden som er tildelt den (alt skjer i løpet av et par nanosekunder, så til brukeren skal det være umerkelig).
En oppfordring til dette API vil bare komme med gitte intervaller - ikke kontinuerlig, så det skal ikke være noen innvirkning på ytelsen.
Nå, kontroller med jevne mellomrom det siste flåttallet mot “Nå”, og hvis forskjellen mellom de to er større enn perioden som anses å være en trygg tomgangsperiode, kan du trimme minnet.
Velg nå etter hvilken tidsperiode du vil anse programmet som inaktiv. Vi bestemte oss for to minutter i mitt tilfelle, men du kan velge hvilken periode du vil, avhengig av omstendighetene.
Å tilpasse denne metoden for lange prosesseringstider eller batchprosesser er ganske enkelt. Normalt har du en god ide hvor en langvarig prosess vil starte (f.eks. Begynnelsen av en løkke som leses gjennom millioner av databaseposter) og hvor den vil slutte (slutten av databasens leseslynge).
Bare deaktiver tidtakeren i begynnelsen av prosessen, og aktiver den igjen på slutten av prosessen.