Den andre koden din kan være mindre i størrelse, men på grunn av funksjonssamtalen overhead blir den maksimale kjøringshastigheten redusert.
Har dette noen betydning i ditt tilfelle? Nei, fordi du uansett har store forsinkelser, men hvis koden var en faktisk serie gjentatte beregninger som skulle utføres så raskt som mulig, ville det utgjøre en forskjell.

Som en generell regel er mindre kode ikke nødvendigvis raskere også.

For kodeoptimalisering (enten størrelse eller hastighet) kan du se dette applikasjonsnotatet fra Atmel AVR4027: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers

Jeg kunne gjenta alt det står her, men jeg tror ikke det er noe poeng, du kan lese den originale artikkelen direkte.

Angående kompilatoroptimalisering nivå. Arduino IDE bruker avr-gcc-kompilatoren med innstilling for Os optimalisering.
De tilgjengelige avr-gcc-optimaliseringsnivåene er ( kilde1 kilde2 )

• O0 eller nei -O alternativ
  På dette optimaliseringsnivået utfører GCC ingen optimalisering og kompilerer kildekoden på den mest enkle måten mulig. Hver kommando i kildekoden konverteres direkte til de tilsvarende instruksjonene i den kjørbare filen, uten omlegging. Dette er det beste alternativet du kan bruke når du feilsøker et program, og er standard hvis ikke noe alternativ for optimaliseringsnivå er spesifisert.

• O1 eller -O
  Dette nivået slår på de vanligste formene for optimalisering som ikke krever avveininger mellom hastighet og rom. Med dette alternativet skal de resulterende kjørbare enhetene være mindre og raskere enn med -O0. De dyrere optimaliseringene, for eksempel instruksjonsplanlegging, brukes ikke på dette nivået. Kompilering med alternativet -O1 kan ofte ta kortere tid enn å kompilere med -O0, på grunn av reduserte mengder data som må behandles etter enkle optimaliseringer.

• O2
  Dette alternativet slår på ytterligere optimaliseringer, i tillegg til de som brukes av -O1. Disse ekstra optimaliseringene inkluderer instruksjonsplanlegging. Bare optimaliseringer som ikke krever avveininger mellom rom og rom, blir brukt, slik at den kjørbare filen ikke skal øke i størrelse. Kompilatoren vil ta lengre tid å kompilere programmer og krever mer minne enn med -O1. Dette alternativet er vanligvis det beste valget for distribusjon av et program, fordi det gir maksimal optimalisering uten å øke den kjørbare størrelsen. Det er standard optimaliseringsnivå for utgivelser av GNU-pakker.

• O3
  Dette alternativet slår på dyrere optimaliseringer, for eksempel funksjonsinnlining, i tillegg til alle optimaliseringene på de lavere nivåene -O2 og -O1. Optimaliseringsnivået -O3 kan øke hastigheten på den resulterende kjørbare filen, men kan også øke størrelsen. Under noen omstendigheter der disse optimaliseringene ikke er gunstige, kan dette alternativet faktisk gjøre et program tregere.

• Os
  Dette alternativet velger optimaliseringer som reduserer størrelsen på en kjørbar fil. Målet med dette alternativet er å produsere den minste mulige kjørbare, for systemer som er begrenset av minne eller diskplass. I noen tilfeller vil en mindre kjørbar også kjøre raskere på grunn av bedre cache-bruk.

Generelt sett er mindre bedre. Imidlertid er det et punkt der for lite faktisk gjør at programmet går tregere.

Mitt forslag er at hvis du jobber med en skisse, og det er åpenbart at du gjentar koden igjen og igjen, vil jeg rive det ut og sette det i en funksjon, ikke bare gjør det programmet mindre, det gjør det lettere å lese.

Det skjer også litt optimalisering bak kulissene også under kompilering, så selv om C / C ++ -koden ser ut til å være stor, er sjansen stor for at kompilatoren / linkeren bestemmer at noe gjentas og konsoliderer dem ... Eller i det minste kan ikke AVR-kompilatoren jeg brukte tidligere huske om Arduino gjør dette.

Når du vurderer optimalisering, bør du tenke nøye gjennom hvilken ressurs som er mest verdifull.

Du kan optimalisere for kodestørrelse; Dette lar deg sette mer kode på prosessoren din. Hva skal resten av plassen brukes til? Hvis koden din ikke passer inn i arduinoen din, og alternativet ditt er å kjøpe en større chip, er dette verdt innsatsen.

Du kan optimalisere for hastighet - du kan kjøre mer kode i samme mengde tid. Hvis du prøver data én gang i sekundet og sover resten av tiden, hjelper dette ikke.

Du kan optimalisere for strømforbruk - veldig viktig hvis du bruker et batteri, mindre viktig hvis du er på strømnettet. Dette er kanskje ikke bare strømforbruket av arduino, men også sensorer &-motorer - kan de slås av en stund?

Det er to optimaliseringer som mange programmerere glemmer - optimalisert for utviklingstid, og optimalisering for lesbarhet.

Enhver optimalisering for en ting vil ha en tendens til å de-optimalisere for minst en (ofte flere) andre ting. Hvis du ikke vet hvilken optimalisering som vil være mest nyttig, så gå for lesbarhet, så utviklingstid (fordi dagens lesbarhet = morgendagens utviklingstid x 10!)

Vanligvis er den dyreste tingen utviklingstid (dvs. DIN tid, spesielt hvis du er på døgnet for en kunde). De fleste andre optimaliseringer har en terskel - så lenge du er over (under?) En bestemt terskel, hjelper ikke ytterligere optimalisering. Kodestørrelse og kjøringshastighet (unntatt når den deles mellom konkurrerende oppgaver) er slik - hvis koden din passer på brikken, er den liten nok. Hvis det trenger å gjøre noe annet senere, kan du optimalisere det da. Hvis programmet ditt kan gjøre alt det trenger (forutsatt at det er sanntid; beregning av Pi er et annet tilfelle), så er det så raskt som det trenger å være.

Refaktoren din bør gjøres bare fordi den er bedre kode, ikke fordi den er mindre. Fordelen er at det er lettere å endre.

Hvis du gjør kodestørrelsen mindre, resulterer det i tap av klarhet (ikke i ditt tilfelle), så bør du sannsynligvis se på det som en for tidlig optimalisering.

Når tiden din er mer verdt mer enn gevinsten du kan oppnå, må du slutte å optimalisere.

Skriver du for noen som skal betale? Da burde dette være deres samtale. Men i dette tilfellet er lesbarhet og klarhet i koden din avgjørende; en dag vil noen andre måtte endre koden din i fravær. Hvis du leverer fungerende kode med høy ytelse som noen andre ikke kan lese og få tak i, vil du ikke ha oppfylt forpliktelsen din (med mindre dette ble spesifikt avtalt).