Code Optimalisatie

by Posted on

Definitie en Eigenschappen

Code optimalisatie is de methode van wijzigingen aan de code te verbeteren, code kwaliteit en efficiency. Een programma kan zo worden geoptimaliseerd dat het kleiner wordt, minder geheugen verbruikt, sneller uitvoert of minder input/output operaties uitvoert.

de basisvereisten waaraan optimalisatiemethoden moeten voldoen, is dat een geoptimaliseerd programma dezelfde output en bijwerkingen moet hebben als de niet-geoptimaliseerde versie. Deze eis, echter, kan worden genegeerd in het geval dat het voordeel van optimalisatie, wordt geschat om belangrijker dan waarschijnlijke gevolgen van een verandering in het gedrag van het programma te zijn.

typen en niveaus van optimalisatie

optimalisatie kan worden uitgevoerd door automatische optimizers of programmeurs. Een optimizer is ofwel een gespecialiseerde software tool of een ingebouwde eenheid van een compiler (de zogenaamde optimizing compiler). Moderne processors kunnen ook het optimaliseren van de volgorde van de uitvoering van de code instructies.

optimalisaties worden ingedeeld in optimalisaties op hoog en laag niveau. Optimalisaties op hoog niveau worden meestal uitgevoerd door de programmeur, die abstracte entiteiten (functies, procedures, klassen, enz.) en houdt rekening met het algemene kader van de taak om het ontwerp van een systeem te optimaliseren. Optimalisaties uitgevoerd op het niveau van elementaire structurele blokken van broncode-loops, takken, enz. – worden meestal aangeduid als high-level optimalisaties te, Terwijl sommige auteurs classificeren ze in een aparte (“midden”) niveau (N. Wirth?). Low-level optimalisaties worden uitgevoerd in het stadium wanneer de broncode wordt gecompileerd in een set van machine-instructies, en het is in dit stadium dat geautomatiseerde optimalisatie meestal wordt gebruikt. Assembler programmeurs geloven echter dat geen enkele machine, hoe perfect ook, dit beter kan dan een ervaren programmeur (toch is iedereen het erover eens dat een slechte programmeur het veel slechter zal doen dan een computer).

wat te optimaliseren

met handmatige code optimalisatie wordt een ander probleem geconfronteerd: men hoeft niet alleen te weten hoe precies optimalisatie moet worden gedaan, maar ook welk specifiek deel van het programma moet worden geoptimaliseerd. Om verschillende redenen (trage invoer, het verschil in de werksnelheid van een menselijke operator en een computer, enzovoort) wordt 90% van de uitvoeringstijd van een programma besteed aan het uitvoeren van slechts 10% van de code (deze uitspraak is nogal speculatief, met het Pareto-principe als een nogal twijfelachtige grond, maar A. Tanenbaum maakt het overtuigend). Aangezien optimalisatie kost extra tijd afgezien van de tijd die je hebt besteed aan het ontwikkelen van het programma, je zou beter richten op het optimaliseren van deze tijd-kritische 10% van de code in plaats van te proberen om het hele programma te optimaliseren. Deze code Fragmenten staan bekend als knelpunten, en kunnen worden gedetecteerd door speciale hulpprogramma ‘ s – profilers – die de tijd die door verschillende delen van het programma uit te voeren kan meten.

in de praktijk gebeurt optimalisatie echter meestal na het stadium van “chaotisch” programmeren(inclusief methoden als “Copy-Paste”, “we zullen later zien”, “it’ s OK this way”), en is daarom een mix van optimalisatie als zodanig, refactoring en bugfixes: vereenvoudiging van “queer” constructies zoals strlen (path.c_str ()), logische voorwaarden zoals (a.x != 0 && a. x != 0), enzovoort. Profilers zijn van weinig hulp bij dit soort optimalisatie. Toch kunt u deze problemen detecteren met statische analyse tools, dat wil zeggen tools ontworpen om te zoeken naar semantische fouten, vertrouwen op diepe analyse van de broncode. Zoals je kunt zien in het bovenstaande voorbeeld met de vreemde conditie, kan inefficiënte code verschijnen als gevolg van fouten (zoals een drukfout in ons voorbeeld, waarbij een. x != 0 && a. y != 0 zou in plaats daarvan moeten zijn). Een krachtige statische analyzer zal dergelijke code fragmenten detecteren en uw aandacht te vestigen op hen door het produceren van waarschuwingsberichten.

goede en slechte resultaten van optimalisatie

in de programmering moet bijna alles worden behandeld vanuit het oogpunt van rationaliteit – optimalisatie is geen uitzondering. Er is een overtuiging dat code geschreven door een onervaren Assembler programmeur 3-5 keer langzamer is dan code gegenereerd door de compiler (Zubkov). Algemeen bekend is een zin door Knuth met betrekking tot vroege low-level optimalisaties (zoals pogingen om te besparen op operators of variabelen): “voortijdige optimalisatie is de wortel van alle kwaad”.

de meeste programmeurs klagen niet over optimalisaties uitgevoerd door de optimizer, waarvan sommige conventioneel en verplicht zijn. Zoals, bijvoorbeeld, staart aanroep optimalisatie in functionele talen (staart aanroep is een speciaal geval van recursie, die kan worden weergegeven als een lus).

men moet echter begrijpen dat meerdere complexe optimalisaties op het niveau van machinecode een grote vertraging van de compilatie kunnen veroorzaken. Het voordeel dat ze u toelaten om te winnen kan veel te onbeduidend zijn, in vergelijking met general system design optimalisations (Wirth). Men moet ook in gedachten houden dat moderne talen, met al hun syntactische en semantische “franje”, hebben vele nuances en subtiliteiten, zodat een programmeur die niet bekend is met hen kan worden verrast door een resultaat van optimalisatie.

bijvoorbeeld, neem C++ en de zogenaamde Return-Value Optimization, wanneer de compiler vermijdt het kopiëren van een tijdelijk object geretourneerd door een functie. Omdat de compiler het kopiëren weglaat, wordt deze methode ook wel “Copy elision”genoemd. Dus, de volgende code:

#include <iostream> struct C { C() {} C(const C&) { std::cout << "A copy was made.\n"; }}; C f() { return C();} int main() { std::cout << "Hello World!\n"; C obj = f();}

kan meerdere uitgangen hebben: 

Hello World!A copy was made.A copy was made.Hello World!A copy was made.Hello World!

hoe vreemd het ook mag lijken, alle drie de versies zijn geldig omdat de taalstandaard in dergelijke gevallen het weglaten van oproepen van een kopiërende constructeur toestaat, zelfs als de constructeur bijwerkingen heeft (§12.8 kopieer objecten, paragraaf 15).

conclusie

daarom moeten we altijd overwegen om de programmacode te optimaliseren met behulp van gespecialiseerde hulpprogramma ‘ s waar mogelijk, maar doe dit met veel zorg, en wees klaar voor de kans op onverwachte trucs van de compiler soms.

PVS-Studio

in de statische analysator PVS-Studio is een set diagnostiek geïmplementeerd die u in staat stelt om situaties te vinden waarin code kan worden geoptimaliseerd. PVS-Studio kan echter, net als elke andere statische analyzer, niet dienen als vervanging van de profiling tools. Alleen dynamische programma analyzers zijn in staat om de knelpunten te identificeren. Statische analyzers weten niet wat invoergegevensprogramma ‘ s krijgen en hoe vaak een bepaald stukje code wordt uitgevoerd. Dat is de reden waarom we zeggen dat de analyzer suggereert de uitvoering van een aantal “micro-optimalisaties” van de code, die niet garanderen dat de prestaties winsten.

ondanks het beschouwde nadeel, fungeert PVS-Studio analyzer als een goede aanvulling op profileringshulpmiddelen. Bovendien, bij het omgaan met PVS-Studio waarschuwingen, gerelateerd aan optimalisatie, code wordt vaak eenvoudiger en korter. Dit effect wordt in meer detail besproken in het artikel “het verkennen van Microoptimalisaties met behulp van Tizen Code als voorbeeld”.

Published by admin

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.