-         

Ergebnis 1 bis 7 von 7

Thema: Optimierungsfrage: select Case oder in eine Gosub springen

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    25.03.2006
    Ort
    Hinsdorf
    Alter
    43
    Beiträge
    379

    Optimierungsfrage: select Case oder in eine Gosub springen

    Anzeige

    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

  2. #2
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    14.01.2008
    Beiträge
    164
    versuchst beide varianten und kontrollierst dann im bascom-simulator welche laufzeit am kürzesten ist.

    so einfach.

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    25.10.2007
    Ort
    41462 Neuss
    Alter
    49
    Beiträge
    375
    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.)

  4. #4
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    25.03.2006
    Ort
    Hinsdorf
    Alter
    43
    Beiträge
    379
    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

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    14.01.2008
    Beiträge
    164
    .....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.

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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)
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  7. #7
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    25.10.2007
    Ort
    41462 Neuss
    Alter
    49
    Beiträge
    375
    Zitat Zitat von mat-sche
    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.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •