Optimierungsfrage: select Case oder in eine Gosub springen

[mat-sche]

N'guten Abend alle miteinand,

ich verschicke über TWI vom Master zum Slave eine Byte, mit dem der Slave dann bestimmte Funktionen ausführen soll.
Meine Frage ist nun was ist ratsamer?!
1. die Funktion in einer select case Anwendung ausführen
oder
2. wenn das richtig Byte eintrifft in eine Gosub springen und dann darin weiter arbeiten?

Was ist Euer Rat?

Gruß MAT

[sechsrad]

versuchst beide varianten und kontrollierst dann im bascom-simulator welche laufzeit am kürzesten ist.

so einfach.

[fumir]

orientier dich lieber an der struktur des programms: welche der möglichkeiten sieht übersichtlicher aus/läßt am besten erkennen was im programm passiert.

die laufzeitunterschiede solcher alternativen sind, wenn überhaupt, klein.
überhaupt sollte man erst mal ein funktionierendes, übersichtliches programm erstellen und erst dann anfangen zu optimieren. dabei sollte man dann auch nicht wild drauflosoptimieren, sondern erst mal herausfinden, in welchem programmteil eine optimierung wirklich notwendig ist, bzw. den besten optimierungseffekt verspricht.

dann sollte man sich gerade beim µC klar machen, das man verschiedene ziele beim optimieren verfolgen kann, z.b.
- geschwindigkeit
- speicherbedarf
- softwarestruktur (flexibilität, wartbarkeit, wiederverwendbarkeit, etc.)

[mat-sche]

Hallo Fumir,

danke für Deine hinreichenden Gedanken!
Bei meinem Gedanken ging es vorrangig über den Speicherbedarf und die Geschwindigkeit.
Im Nachhinein zu optimieren ist eine ganz gute Sache, dass aber bei größeren Programmen zum verhängnis werden kann, oder nicht :) .

Ich werde meinen Code erstmal der Übersichtlichkeit aufbauen und dann mal schauen was "geht" ;) .

Gruß MAT

[sechsrad]

.....welche der möglichkeiten sieht übersichtlicher aus/läßt am besten erkennen was im programm passiert. .....


das eben ist in bascom ein buch mit sieben siegeln.
der befehl sagt nichts aus für den laien, wie der der timer und welcher timer benutzt wird.
man wundert sich halt nur , das plötztlich eigene kreationen nicht mehr funktionieren.

ein bisschen chaos kann nicht schaden, es geht darum den kleinen atmega optimal auszureizen.

seh dir mal die programme von winavr-c an. wie chaotisch die geschrieben sind, werden dadurch aber auch sehr schnell.

also lass dich nicht von der kastendenkform beeinflussen.

[PicNick]

Recht kompakt ist die "ON" VAriante,
ON command GOTO routine-1, routine-2, ........ routine-x
(type "help" for help, geht auch mit "GOSUB")
besonders, wenn "command" einen halbwegs geschlossenen Werte-bereich hat (also z.B. 0-7 oder sowas)

[fumir]

Im Nachhinein zu optimieren ist eine ganz gute Sache, dass aber bei größeren Programmen zum verhängnis werden kann, oder nicht :) .

gerade bei größeren programmen, ist es wichtig eine gute programmstruktur zu haben.
man kann ja auf verschiedenen ebenen optimieren:
- softwarearchitektur (highlevel)
- algorithmen
- implementierung (lowlevel)
insofern wäre es sicher falsch, ein programm fertig zu schreiben und es erst dann auf highlevel zu optimieren. aber genauso falsch ist es eben, mit irgendwelchen lowlevel-optimierungen anzufangen, wenn die programmstruktur als solche noch optimierbar ist.

in der regel bringen highlevel-optimierungen wesentlich mehr als lowlevel-optimierungen.

anders gesagt: erst mal den optimalen algorithmus finden und dann erst den algorithmus möglichst gut umsetzen. ein beispiel: du kannst einen noch so guten quicksort programmieren - wenn die daten nicht zum algorithmus passen (weil sie womöglich schon weitgehend vorsortiert sind oder ne andere besonderheit aufweisen) dann ist quicksort ungeeignet, und andere methoden sind schneller.