Na druhou stranu by se patrilo dodat a ZDURAZNIT, ze predcasna optimalizace je korenem vseho zla. (A nevhodna optimalizazce taky.)
Takze pokud se vam na Arduinu vejde program do flasky, tak je NAPROSTO ZBYTECNE ho optimalizovat na velikost, protoze v te flasce uz nic jineho nebude a co nepouzije program, to bude proste lezet ladem a neprinese zadny uzitek.
Dokud vam nechodi spravne a spolehlive, tak nema cenu ho optimalizovat na rychlost a vetsinou ani na obsazenou RAM (pokud to kvuli ni nepada jeste pred vyskytem prvni chyby), ale naopak je treba ho optimalizovat na citelnost a spravnou funkci.
Komentare a spravne odsazeni se pri prekladu odfitrujou a nestoji to na vykonu nic. (Ten zlomek sekundy pri prekladu je smesny v porovnani s dobou prekladu vsech tech knihoven okolo.) Na druhou stranu vam usetri ne minuty, ale obvykle hodiny a dny pri psani a ladeni programu. Rozumnych komentaru neni nikdy moc.
Existuji aplikace, kde 10 instrukci spalenych na volani interruptu hraje roli. Volani funkce stoji obvykle jeste vic, pouziti parametru misto globalni promenne vas prijde asi na 4 takty pri volani funkce a 1-2 takty pri pouziti. Pouziti int misto byte vas prijde asi na 4 nasobek taktu pri kazdem pouziti, stejne tal pouziti long misto int.
Jedine zavolani delay(1) vas prijde na 16.0000 taktu.
Pokud uz potrebujete optimalizovat, optimalizujte vzdy tam, kde to ma nejvetsi efekt. (Coz vetsinou znamena profilovani, nebo dukladnou analyzu, nebo aspon nejake logy - ktere samy taky zdaleka nejsou zdarma).
Naopak pouzit dlouhych_a_popisnych_jmen_promennych oproti x,_x,x1 a x2 nestoji vubec nic - prekladac je stejne nahradi adresama - tudiz pouzivejte dlouhe a popisne jmena - pri preklepu z x na c vam prekladac nic nerekne, pokud obe existuji. Pri preklepu v dlouhem jmene je miziva sance, ze byste trefili neco jineho a tudiz se chyba odhali pri prvnim pokusu o preklad.
Pokud sem pisete z prohlizece mladsiho 5 let, tak vas vliv na dobu prekladu a potrebna pamet pro nej NEZAJIMA - jedina chyba ci oprava vam ztrati radove vic casu, nez libovolna uspora dosazitelna v programu. (A nutno dodat, ze vetsinu z toho casu stravite v editoru a pri premysleni, nikoli prekladem)
Pokud vas prece jen trapi vykon vasi aplikace a vejdete se do pameti (predpokladam, ze vsech delay() jste se zbavili uz davno), tak se zamyslete nad pouzitym algoritmem - spatny algoritmus klidne prodlouzi vypocty o nekolik (ci mnoho) radu, o minuty, dny, roky ...
Pokud je algoritmus efektivni a porad to jeste nestaci, omezte zbytecne volani knihovnich funkci (cili vseho co je v Arduinu "tak nejak samo"), daji se tim dosahnout dalsi radove uspory - misto nastavovani hodnoty LED pri kazdem pruchodu smyckou ji nastavujte jen kdyz se skutecne meni (a zapamatujte si, v jakem je stavu, at na to nemusite pouzivat pomaly a komplikovany digitalRead)
A projdete si, co delaji knihovny (zvlast, pokud je pouzivate i na jednoduche veci jako tlacitka, nikoli jen na ty slozite jako wifi ci ethernet).
A (nejen ladici) vypisy udelejte strucne, ale vystizne (kdo z vas vi, ze Serial si nastavuje vnitrni buffer v zavislosti na tom, kolik mate volne RAM - takze ma bud 32, nebo 64 byte - a ze pokud odeslete "naraz" min znaku, tak to volani neni blokujici a vypocet pokracuje, zatimco pokud poslete byt jen o znak vic (tedy 32+/64+, vcetne enteru a pod), tak se to zastavi, dokud se toho neodvysila dost - coz taky muze trvat)
A samozrejme je pak (kdyz musime setrit) lepsi udelat serii
Kód: Vybrat vše
Serial.write("x=");
Serial.write( x );
Serial.write(";y=");
Serial.write( y );
Serial.write(";val=");
Serial.println( hodnota_mereni );
nez
Kód: Vybrat vše
String msg= "x="; // String je objekt
msg += x + ";y=" + y + ";val=" + hodnota_mereni; // a tady jich udelame spoustu a dynamicky alokujeme pamet, abychom ji zase uvolnovali
Serial.println(msg);
protoze ta serie nevysiluje s objekty a je uspornejsi jak na pamet, tak na vypocty, zatimco druha metoda je zase o neco prehlednejsi, ale narocnejsi
A z vice ruznych duvodu (a Serial je jednim z nich) je vyhodnejsi udelat loop() ktera probehne co nejrychleji, nez v ni zdrzovat necim, co by se dalo rozhodit do vic pruchodu (viz blikame bez delay, nebo
http://micro-corner.gilhad.cz/blog/Ardu ... ouse2.html kde mam velmi rychly stavovy automat )