Bij het schrijven van langlopende applicaties - het soort programma's dat het grootste deel van de dag zal worden geminimaliseerd naar de taakbalk of systeemvak, kan het belangrijk worden om het programma niet te laten 'wegrennen' met geheugengebruik.
De twee meest rechtse kolommen geven CPU-gebruik (tijd) en geheugengebruik aan. Als een proces ernstige gevolgen voor een van beide heeft, zal uw systeem langzamer werken.
Het soort dingen dat vaak van invloed is op het CPU-gebruik is een programma dat in een lus wordt weergegeven (vraag een programmeur die is vergeten een "read next" -instructie in een lus voor bestandsverwerking te plaatsen). Dat soort problemen zijn meestal vrij eenvoudig te verhelpen.
Geheugengebruik daarentegen is niet altijd duidelijk en moet meer dan gecorrigeerd worden beheerd. Neem bijvoorbeeld aan dat een vastlegtype-programma actief is.
Dit programma wordt de hele dag door gebruikt, mogelijk voor telefonische vastlegging bij een helpdesk of om een andere reden. Het is gewoon niet logisch om het elke twintig minuten uit te schakelen en vervolgens opnieuw op te starten. Het wordt de hele dag door gebruikt, hoewel met zeldzame tussenpozen.
Als dat programma afhankelijk is van een zware interne verwerking of veel illustraties op zijn vormen heeft, vroeg of laat zijn geheugengebruik gaat groeien, waardoor er minder geheugen overblijft voor andere, frequentere processen, de paging-activiteit wordt opgevoerd en de computer uiteindelijk wordt vertraagd.
Stel dat u een programma gaat ontwerpen met de hoofdvorm en twee aanvullende (modale) vormen. Afhankelijk van uw Delphi-versie gaat Delphi meestal de formulieren in de invoegen project eenheid (DPR-bestand) en bevat een regel om alle formulieren te maken bij het opstarten van de applicatie (Application. CreateForm (...)
De lijnen in de projecteenheid zijn van het Delphi-ontwerp en zijn geweldig voor mensen die niet bekend zijn met Delphi of die het net beginnen te gebruiken. Het is handig en behulpzaam. Het betekent ook dat ALLE formulieren worden gemaakt wanneer het programma wordt gestart en NIET wanneer ze nodig zijn.
Afhankelijk van waar uw project over gaat en de functionaliteit die u een formulier hebt geïmplementeerd, kan veel geheugen worden gebruikt, dus formulieren (of in het algemeen: objecten) mogen alleen worden gemaakt als dat nodig is en vernietigd (bevrijd) zodra ze niet langer zijn vereist.
Zowel "DialogForm" als "OccasionalForm" moeten worden verwijderd uit de lijst met "Formulieren automatisch maken" en worden verplaatst naar de lijst "Beschikbare formulieren".
Merk op dat de hier geschetste strategie is gebaseerd op de veronderstelling dat het programma in kwestie een programma van het type "vastleggen" is. Het kan echter eenvoudig worden aangepast voor batch-type processen.
Delphi heeft geprobeerd dit te minimaliseren en heeft zijn eigen geheugenbeheerarchitectuur die veel kleinere blokken gebruikt, maar dit is het vrijwel nutteloos in de Windows-omgeving omdat de geheugentoewijzing uiteindelijk bij het besturingssysteem ligt.
Zodra Windows een geheugenblok heeft toegewezen aan een proces en dat proces 99,9% van het geheugen vrijmaakt, Windows ziet nog steeds dat het hele blok in gebruik is, zelfs als er maar één byte van het blok is gebruikt. Het goede nieuws is dat Windows een mechanisme biedt om dit probleem op te lossen. De shell biedt ons een API genaamd SetProcessWorkingSetSize. Dit is de handtekening:
Per definitie stelt de functie SetProcessWorkingSetSize de minimale en maximale werksetgrootten in voor het opgegeven proces.
Deze API is bedoeld om een lage niveau-instelling van de minimale en maximale geheugengrenzen voor de geheugengebruiksruimte van het proces mogelijk te maken. Het heeft echter een kleine eigenaardigheid ingebouwd die het meest gelukkig is.
Als zowel de minimum- als de maximumwaarde zijn ingesteld op $ FFFFFFFF, zal de API de ingestelde grootte tijdelijk inkorten tot 0, deze uit het geheugen verwisselen en meteen kaatst terug in RAM, het zal de absolute minimale hoeveelheid geheugen toegewezen krijgen (dit gebeurt allemaal binnen een paar nanoseconden, dus voor de gebruiker zou het moeten zijn onmerkbaar).
Een oproep naar deze API wordt alleen gedaan met bepaalde intervallen - niet continu, dus er is helemaal geen invloed op de prestaties.
Controleer nu regelmatig het laatste aantal vinkjes met "Nu" en als het verschil tussen de twee groter is dan de periode die als een veilige periode van inactiviteit wordt beschouwd, moet u het geheugen bijsnijden.
Beslis nu na welke periode u het programma als inactief zult beschouwen. We hebben in mijn geval twee minuten gekozen, maar u kunt elke gewenste periode kiezen, afhankelijk van de omstandigheden.
Het is vrij eenvoudig om deze methode aan te passen voor lange verwerkingstijden of batchprocessen. Normaal gesproken zult u een goed idee hebben waar een langdurig proces zal beginnen (bijv. Het begin van een lus die door miljoenen database-records leest) en waar het eindigt (einde van de database-leeslus).
Schakel eenvoudig uw timer uit aan het begin van het proces en schakel deze opnieuw in aan het einde van het proces.