Toisen koodisi koko voi olla pienempi, mutta toimintokutsujen yläpuolella maksimi suorituksen nopeus pienenee.
Onko tämä merkitystä sinun tapauksessasi? Ei, koska sinulla on joka tapauksessa suuria viivästyksiä, mutta jos koodi olisi varsinainen sarja toistuvia laskutoimituksia, jotka tulisi suorittaa mahdollisimman nopeasti, se tekisi eron.

Yleensä pienempi koodi on ei välttämättä myöskään nopeammin.

Koodin optimoinnista (joko koosta tai nopeudesta) saat tämän Atmel-sovelluksen huomautuksen AVR4027: Vinkkejä ja vihjeitä C-koodisi optimointiin 8-bittisille AVR-mikrokontrollereille

Voisin toistaa kaiken, mitä täällä sanotaan, mutta mielestäni ei ole mitään syytä, voit lukea alkuperäisen artikkelin suoraan.

Kääntäjän optimoinnista taso. Arduino IDE käyttää avr-gcc-kääntäjää asetuksella Os -optimointiin.
Avr-gcc: n käytettävissä olevat optimointitasot ovat ( source1 source2 )

• O0 tai ei -O-vaihtoehto
  Tällä optimointitasolla GCC ei tee mitään optimointia ja kääntää lähdekoodin suorimmalla tavalla mahdollista. Jokainen lähdekoodin komento muunnetaan suoraan vastaaviksi suoritustiedoston ohjeiksi ilman uudelleenjärjestelyä. Tämä on paras vaihtoehto ohjelman virheenkorjauksessa ja se on oletusarvo, jos optimointitason vaihtoehtoa ei ole määritetty.

• O1 tai -O
  Tämä taso ottaa käyttöön yleisimmät optimointimuodot, jotka eivät vaadi nopeus-avaruus-kompromisseja. Tällä vaihtoehdolla tuloksena olevien suoritettavien tiedostojen tulisi olla pienempiä ja nopeampi kuin -O0: lla. Kalliimpia optimointeja, kuten käskyjen ajoitusta, ei käytetä tällä tasolla. Vaihtoehdolla -O1 kokoaminen voi usein viedä vähemmän aikaa kuin -O0: lla, johtuen pienemmistä tietomääristä, jotka on käsiteltävä yksinkertaisten optimointien jälkeen.

• O2
  Tämä vaihtoehto ottaa käyttöön muita optimointeja niiden lisäksi, joita -O1 käyttää. Nämä lisäoptimoinnit sisältävät käskyjen ajoituksen. Käytetään vain optimointeja, jotka eivät vaadi nopeus-avaruus-kompromisseja, joten suoritettavan tiedoston ei pitäisi kasvaa. Kääntäjä vie kauemmin ohjelmien kääntäminen ja vaatii enemmän muistia kuin -O1. Tämä vaihtoehto on yleensä paras valinta ohjelman käyttöönottoon, koska se tarjoaa maksimaalisen optimoinnin lisäämättä suoritettavan koon määrää. Se on GNU-pakettien julkaisujen oletusoptimointitaso.

• O3
  Tämä vaihtoehto ottaa käyttöön kalliimpia optimointeja, kuten toimintojen rivitys, kaikkien alempien tasojen -O2 optimointien lisäksi. ja -O1. -O3-optimointitaso voi lisätä tuloksena olevan suoritettavan tiedoston nopeutta, mutta voi myös lisätä sen kokoa. Joissakin olosuhteissa, joissa nämä optimoinnit eivät ole suotuisia, tämä vaihtoehto saattaa todella hidastaa ohjelmaa.

• Os
  Tämä vaihtoehto valitsee optimoinnit, jotka pienentävät suoritettavan tiedoston kokoa. Tämän vaihtoehdon tarkoituksena on tuottaa pienin mahdollinen suoritettava tiedosto muistin tai levytilan rajoittamille järjestelmille. Joissakin tapauksissa myös pienempi suoritettava tiedosto toimii nopeammin välimuistin paremman käytön vuoksi.

Yleisesti ottaen pienempi on parempi. On kuitenkin kohta, jossa liian pieni tosiasiassa tekee ohjelman ajamisesta hitaamman.

Ehdotan, että jos työskentelet luonnoksen parissa, on ilmeisen ilmeistä, että toistat koodia uudestaan ​​ja uudestaan, haluaisin repäise se ulos ja laita se funktioon, se ei vain pienennä ohjelmaa, vaan myös helpottaa lukemista.

Kulissien takana tapahtuu myös jonkin verran optimointia käännöksen aikana, joten vaikka C / C ++ -koodi näyttää olevan suuri, kääntäjä / linkittäjä on todennäköistä, että jokin toistuu ja vahvistaa ne ... Tai ainakaan aiemmin käyttämäni AVR-kääntäjä, ei muista, tekeekö Arduino tämän.

Kun harkitset optimointia, mieti tarkkaan, mikä resurssi on arvokkain.

Voit optimoida koodin koon mukaan; tämän avulla voit laittaa lisää koodia prosessoriin. Mihin lopputilaa käytetään? Jos koodisi ei mahdu arduinoon ja vaihtoehto on ostaa suurempi siru, se on vaivan arvoista.

Voit optimoida nopeutta varten - voit käyttää enemmän koodia samalla määrällä aika. Jos otat tietoja kerran sekunnissa ja nukut lopun ajan, tämä ei auta.

Voit optimoida virrankäyttöä - erittäin tärkeää, jos käytät akkua, vähemmän tärkeää jos olet verkkovirrassa. Tämä ei välttämättä ole pelkästään arduinon kuluttama teho, vaan myös &-moottoreiden anturit - voidaanko ne sammuttaa hetkeksi?

Monet ohjelmoijat unohtavat kaksi optimointia - optimointi kehitysaikaa varten, ja optimointi luettavuutta varten.

Kaikki yhden asian optimoinnit pyrkivät optimoimaan ainakin yhden (usein useita) muita asioita. Jos et tiedä mikä optimointi on eniten hyötyä, valitse sitten luettavuus ja sitten kehitysaika (koska tämän päivän luettavuus = huomisen kehitysaika x 10!)

Yleensä kallein asia on kehitysaika (ts. OMA aikasi, varsinkin jos olet kellossa asiakkaalle) Suurimmalla osalla muusta optimoinnista on kynnys - niin kauan kuin olet ylittänyt (alle?) Tietyn kynnyksen, lisäoptimointi ei auta. Koodin koko ja suoritusnopeus (paitsi jos jaettu kilpailevien tehtävien välillä) ovat tällöin - jos koodisi mahtuu sirulle, se on riittävän pieni. Jos sen on tehtävä jotain muuta myöhemmin, voit optimoida sen sitten. Jos ohjelmasi pystyy tekemään kaiken tarvittavan (olettaen, että se on reaaliaikainen; Pi: n laskeminen on erilainen tapaus), niin se on niin nopeaa kuin sen täytyy olla.

Refaktorisi tulisi tehdä vain siksi, että se on parempi koodi, ei siksi, että se on pienempi. Etuna on, että sitä on helpompi muokata.

Jos koodikoon pienentäminen johtaa selkeyden menetykseen (ei sinun tapauksessasi), sinun on todennäköisesti katsottava sitä ennenaikaisena optimointina.

Kun aikaasi on enemmän kuin voitot, lopeta optimointi.

Kirjoitatko jonkun maksettavaksi? Tämän pitäisi olla heidän kutsunsa. Mutta tässä tapauksessa koodisi luettavuus ja selkeys on ensiarvoisen tärkeää; jonain päivänä jonkun muun on muokattava koodiasi poissaollessasi. Jos toimitat toimivan, korkean suorituskyvyn koodin, jota joku muu ei osaa lukea ja saada käsityksen, et ole täyttänyt velvollisuuttasi (ellei tästä ole erikseen sovittu).