När du skriver applikationer med lång drift - den typ av program som kommer att tillbringa större delen av dagen minimeras till aktivitetsfältet eller systemfältet, kan det bli viktigt att inte låta programmet "fly" med minnesanvändning.
De två högsta kolumnerna indikerar CPU (tids) användning och minnesanvändning. Om en process påverkar någon av dessa allvarligt kommer ditt system att sakta ner.
Den typen av saker som ofta påverkar CPU-användningen är ett program som loopar (fråga alla programmerare som har glömt att lägga ett "läs nästa" uttalande i en filbehandlingsslinga). Sådana problem korrigeras vanligtvis ganska enkelt.
Å andra sidan är minnesanvändning inte alltid uppenbar och behöver hanteras mer än korrigeras. Antag till exempel att ett program för inspelningstyp körs.
Detta program används hela dagen, eventuellt för telefonisk fångst vid en helpdesk eller av någon annan anledning. Det är inte vettigt att stänga av den varje tjugo minut och sedan starta upp den igen. Det kommer att användas under hela dagen, även om det inte sker ofta.
Om det programmet förlitar sig på någon tung intern bearbetning eller har massor av konstverk på dess former, förr eller senare minnesanvändning kommer att växa, vilket ger mindre minne för andra mer frekventa processer, driver upp personsökningsaktiviteten och slutligen bromsar datorn.
Låt oss säga att du kommer att utforma ett program med huvudformuläret och två ytterligare (modala) former. Beroende på din Delphi-version kommer Delphi vanligtvis att infoga formulärerna i projektenhet (DPR-fil) och kommer att innehålla en rad för att skapa alla formulär vid programstart (Application. CreateForm (...)
Linjerna som ingår i projektenheten är av Delphi design och passar bra för personer som inte känner till Delphi eller bara börjar använda den. Det är bekvämt och användbart. Det betyder också att ALLA formulär kommer att skapas när programmet startas och INTE när de behövs.
Beroende på vad ditt projekt handlar om och vilken funktionalitet du har implementerat ett formulär kan använda mycket minne, så formulär (eller i allmänhet: föremål) bör endast skapas vid behov och förstöras (frigöras) så snart de inte längre är nödvändig.
Både "DialogForm" och "OccasionalForm" måste tas bort från listan med "Auto-create forms" och flyttas till listan "Available Forms".
Observera att strategin som beskrivs här är baserad på antagandet att programmet i fråga är ett realtidsprogram av typen "capture". Det kan emellertid enkelt anpassas för processer av buntyp.
Delphi har försökt att minimera detta och har en egen minneshanteringsarkitektur som använder mycket mindre block men det är det praktiskt taget värdelös i Windows-miljön eftersom minnesallokationen till slut beror på operativsystemet.
När Windows har tilldelat ett block av minne till en process och den processen frigör 99,9% av minnet, Windows kommer fortfarande att uppfatta att hela blocket ska användas, även om bara en byte av blocket faktiskt används Begagnade. Den goda nyheten är att Windows tillhandahåller en mekanism för att rensa upp problemet. Skalet ger oss ett API som heter SetProcessWorkingSetSize. Här är signaturen:
Per definition ställer funktionen SetProcessWorkingSetSize in minsta och maximala arbetsuppsättningsstorlek för den angivna processen.
Detta API är avsett att möjliggöra en låg nivåinställning av minimi- och maxminnesgränserna för processens minnesanvändningsutrymme. Det har emellertid ett litet inbyggt inbyggt i det som är mest lyckligt.
Om både minimi- och maximivärdena är inställda på $ FFFFFFFF, kommer API tillfälligt att trimma den inställda storleken till 0, byta ut den från minnet och omedelbart som den studsar tillbaka till RAM, det kommer att ha den absoluta minsta mängden minne tilldelad det (allt händer inom ett par nanosekunder, så för användaren borde det vara omärklig).
Ett samtal till detta API kommer bara att göras med givna intervall - inte kontinuerligt, så det bör inte ha någon inverkan alls på prestanda.
Kontrollera nu regelbundet det sista fästet mot "Nu" och om skillnaden mellan de två är större än den period som anses vara en säker tomgångsperiod, klipp av minnet.
Bestäm nu efter vilken tidsperiod du anser att programmet är inaktivt. Vi beslutade om två minuter i mitt fall, men du kan välja vilken period du vill beroende på omständigheterna.
Att anpassa den här metoden för långa bearbetningstider eller batchprocesser är ganska enkelt. Normalt har du en bra idé om en lång process kommer att starta (t.ex. början av en slingläsning genom miljontals databasposter) och var den kommer att slutas (slutet på databaslässlingan).
Inaktivera helt enkelt din timer i början av processen och aktivera den igen i slutet av processen.