Assemblerzeilen zählen bringt nur wenig.
Ausser wenn es nur um den Flash-Verbrauch geht.
Das ist mir eigentlich klar, daher habe ich ja gefragt, wie man bei einzelnen Routinen feststellen kann wie schnell (in wieviel Takten) diese ausgeführt werden.

- überprüfen ob dinge doppelt oder unnütz berechnet werden
Die Gefahr ist bei einem grösseren Programm sicherlich gegeben.
Dass man das selber prüfen muss und die Entscheidung welche Programmteile unnütz sind nicht irgendeinem Tool oder dem Compiler überlässt, finde ich aber eigentlich ganz OK

- überprüfen, ob funktionen oder werte nicht als tabelle im speicher vorab abgelegt werden können
Das wird vermutlich erst ab einer gewissen "Komplexität" der Funktionen Vorteile bringen und wenn ich da richtig liege, ist es halt hilfreich, wenn man den Erfolg auch prüfen kann.

- möglichst subs oder funktionen vermeiden, sondern gosub verwenden
OK, das ist mir neu. Kommt mir aber entgegen, da ich eigentlich immer zu faul war Subs und Funktionen zu nutzen und mir das erst in diversen Codeschnipseln und Beispielprogrammen abgeguckt habe.

Eine Möglichkeit, die Erfolge von Optimierungen zu überprüfen ist, am Anfang des betreffenden Codes einen Counter zu starten und diesem an Ende des Codes auszulesen.
Ich habe es mal über nen Zähler in einer Interrupt-Routine versucht, dabei aber irgendwie so rumgemurkst, dass nichts sinnvolles dabei rauskam.
Einen Counter zu verwenden ist ein guter Plan

Reicht es, wenn man das im Simulator macht oder pfuscht da das seltsame Verhalten von Windows rein?
Um die Takte über einen Counter zu zählen sollte ja eigentlich der Simulator reichen und das Multitasking von Windows keine Rolle spielen.