Kodeoptimalisering

• Innhold
• Definisjon Og Egenskaper
• Typer Og Nivåer Av Optimalisering
• Hva Å Optimalisere
• Gode Og Dårlige Resultater Av Optimalisering
• Konklusjon
• PVS-Studio

Innhold

• Definisjon Og Egenskaper
• Typer Og Nivåer Av Optimalisering
• Hva Som Skal Optimaliseres
• Gode Og Dårlige Resultater Av Optimalisering
• Konklusjon
• PVS-Studio

Definisjon Og Egenskaper

Kodeoptimalisering Er En Hvilken Som Helst Metode For Kodeendring for å forbedre Kodekvaliteten Og Effektiviteten. Et program kan optimaliseres slik at det blir en mindre størrelse, bruker mindre minne, utfører raskere, eller utfører færre input/output operasjoner.

de grunnleggende kravene optimaliseringsmetoder bør overholde, er at et optimalisert program må ha samme utgang og bivirkninger som sin ikke-optimaliserte versjon. Dette kravet kan imidlertid ignoreres i tilfelle at fordelen av optimalisering, anslås å være viktigere enn sannsynlige konsekvenser av en endring i programadferden.

Typer Og Nivåer Av Optimalisering

Optimalisering kan utføres av automatiske optimalisatorer eller programmerere. En optimizer er enten et spesialisert programvareverktøy eller en innebygd enhet av en kompilator (den såkalte optimaliseringskompilatoren). Moderne prosessorer kan også optimalisere kjørerekkefølgen for kodeinstruksjoner.

Optimaliseringer klassifiseres i optimaliseringer på høyt og lavt nivå. Optimaliseringer på høyt nivå utføres vanligvis av programmereren, som håndterer abstrakte enheter (funksjoner, prosedyrer, klasser, etc.) og husker det generelle rammeverket for oppgaven å optimalisere utformingen av et system. Optimaliseringer utført på nivå med elementære strukturelle blokker av kildekode-looper , grener, etc. – er vanligvis referert til som høyt nivå optimaliseringer også, mens noen forfattere klassifisere dem i en egen (“midten”) nivå (N. Wirth?). Lavt nivå optimaliseringer utføres på scenen når kildekoden er kompilert i et sett med maskininstruksjoner, og det er på dette stadiet at automatisert optimalisering vanligvis brukes. Assembler programmerere tror imidlertid at ingen maskin, men perfekt, kan gjøre dette bedre enn en dyktig programmerer (men alle er enige om at en dårlig programmerer vil gjøre mye verre enn en datamaskin).

Hva Å Optimalisere

med manuell kodeoptimalisering står man overfor et annet problem: man trenger ikke bare å vite hvordan nøyaktig optimalisering skal gjøres, men også hvilken bestemt del av programmet som skal optimaliseres. På grunn av ulike årsaker (treg inngangsoperasjoner, forskjellen i arbeidshastigheten til en menneskelig operatør og en datamaskin, og så videre), blir 90% av utførelsestiden til et program brukt til å utføre bare 10% av koden (denne uttalelsen er ganske spekulativ, Med Pareto-prinsippet som en ganske tvilsom grunn, Men A. Tanenbaum gjør det lyd overbevisende). Siden optimalisering tar ekstra tid bortsett fra tiden du har brukt på å utvikle programmet, kan du bedre fokusere på å optimalisere denne tidskritiske 10% av koden i stedet for å prøve å optimalisere hele programmet. Disse kodefragmentene er kjent som flaskehalser, og kan oppdages av spesielle verktøy – profilere – som kan måle tiden det tar av ulike deler av programmet å utføre.

i praksis gjøres imidlertid optimalisering vanligvis etter scenen med “kaotisk” programmering(inkludert slike metoder som” Copy-Paste”, “vi ser senere”, “det ER OK på denne måten”), og er derfor en blanding av optimalisering som sådan, refactoring og feilrettinger: forenkling av “queer” konstruksjoner som strlen(path.c_str ()), logiske forhold som (a.x != 0 & & a.x != 0) og så videre. Profilere er til liten hjelp med denne typen optimalisering. Likevel kan du oppdage disse problemene med statiske analyseverktøy, dvs. verktøy designet for å søke etter semantiske feil, avhengig av dyp analyse av kildekoden. Som du kan se fra ovennevnte eksempel med den merkelige tilstanden, kan ineffektiv kode vises som følge av feil (som et feiltrykk i vårt eksempel, hvor a.x != 0 & &a. y!= 0 bør være i stedet). En kraftig statisk analysator vil oppdage slike kodefragmenter og trekke oppmerksomheten mot dem ved å produsere advarsler.

Gode Og Dårlige Resultater Av Optimalisering

i programmering bør nesten alt behandles fra rasjonalitetens synspunkt-optimalisering er ikke noe unntak . Det er tro på at kode skrevet av en uerfaren Assembler programmerer er 3-5 ganger langsommere enn kode generert av kompilatoren (Zubkov). Viden kjent Er En frase Fra Knuth om tidlig lavt nivå optimaliseringer (for eksempel forsøk på å spare på operatører eller variabler): “Prematur optimalisering er roten til alt ondt”.

de fleste programmerere klager ikke på optimaliseringer utført av optimizer, hvorav noen er konvensjonelle og obligatoriske. Slik som for eksempel optimalisering av haleanrop i funksjonelle språk (haleanrop er et spesielt tilfelle av rekursjon, som kan representeres som en sløyfe).

imidlertid bør man forstå at flere komplekse optimaliseringer på nivået med maskinkode kan føre til en stor nedbremsing av kompilering. Fordelen de tillater deg å få kan være altfor ubetydelig, sammenlignet med generelle system design optimaliseringer (Wirth). Man bør også huske på at moderne språk, med alle sine syntaktiske og semantiske “frills”, har mange nyanser og finesser, slik at en programmerer som ikke er kjent med dem, kan bli overrasket over et resultat av optimalisering.

ta For Eksempel C++ og Den såkalte Returverdi Optimalisering, når kompilatoren unngår å kopiere et midlertidig objekt returnert av en funksjon. Fordi kompilatoren utelater kopiering, kalles denne metoden også “Copy elision”. Så, følgende kode:

#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 ha flere utganger:

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

Merkelig nok er alle de tre versjonene gyldige fordi språkstandarden tillater å utelate samtaler fra en kopieringskonstruktør i slike tilfeller, selv om konstruktøren har bivirkninger (§12,8 Kopieringsklasseobjekter, Avsnitt 15).

Konklusjon

derfor bør vi alltid vurdere å optimalisere programkoden ved hjelp av spesialiserte verktøy der det er mulig, men gjør dette med stor forsiktighet, og vær klar for sannsynligheten for uventede triks fra kompilatoren til tider.

PVS-Studio

et sett med diagnostikk er implementert i den statiske analysatoren PVS-Studio som gjør at du kan finne noen situasjoner der koden kan optimaliseres. PVS-Studio som enhver annen statisk analysator kan imidlertid ikke fungere som en erstatning for profileringsverktøyene. Bare dynamiske programanalysatorer kan identifisere flaskehalsene. Statiske analysatorer vet ikke hvilke inndataprogrammer som får og hvor ofte et bestemt stykke kode utføres. Det er derfor vi sier at analysatoren foreslår å implementere noen “mikrooptimaliseringer” av kode, som ikke garanterer ytelsesgevinstene.

TIL tross for den vurderte ulempen fungerer PVS-Studio analyzer som et godt supplement til profileringsverktøy. Videre, når det gjelder PVS-Studio advarsler, relatert til optimalisering, blir koden ofte enklere og kortere. Denne effekten vurderes mer detaljert i artikkelen “Utforske Mikrooptimaliseringer Ved Hjelp Av Tizen-Kode som Et Eksempel”.