leider nein, ich kenne den app-inventor nicht, aber das verhalten wird schon ein anderes sein als bei Ardroid...
Druckbare Version
leider nein, ich kenne den app-inventor nicht, aber das verhalten wird schon ein anderes sein als bei Ardroid...
Hallo fredyxx,
Das ist jetzt halt der Unterschied zwischen der Klötzchen-Programmierung und einer Programmiersprache!Zitat:
Zitat von fredyxx
Logisch machen beide Varianten das Selbe, die Wege sind aber unterschiedlich.
Über eine Programmiersprache kann man alles steuern und hat auch die Übersicht, was unmittelbar zusammengehört. Man kann also in deinem Fall die Teil-Texte zuerst in einem Puffer zusammensetzen und dann den gesamten Puffer ausgeben. Man weiss, dass zwischen dem ersten und dem zweiten Teil nicht etwa 10 Sekunden noch etwas anderes gemacht werden muss.
Bei der Klötzchen-Programmierung braucht man definierte Zustände, wenn so ein Klötzchen abgearbeitet ist. Dazu gehört halt auch, dass Sendepuffer sofort geschrieben werden. So ein einzelnes Klötzchen weiss nicht, wie es nach ihm weiter geht.
Ein weiterer Punkt ist noch, dass die Klötzchen-Geschichte langsam ist. Da ist für jedes Klötzchen zuerst einiges vorzubereiten und nach Beendigung wieder aufzuräumen. Zudem ist das meistens ein Interpreter.
In beiden Varianten muss zwischen den beiden Teil-String noch etwas gerechnet werden. Bei den Klötzchen fällt die Rechenzeit halt auf. Vermutlich ist bei beiden Varianten bei der Ausgabe eine Pause dazwischen, aber 1/10 Sekunde fällt nicht wirklich auf.
MfG Peter(TOO)
Hallo,
endlich habe ich die Ursache gefunden, die nichts mit AppInventor oder Klötzchen-Programmierung zu tun hat, und wenn man die Lösung kennt, primitiv ist!
In meiner ersten Frage seht ihr, dass ich beim Einlesen eines empfangenen Telegramms als Endezeichen ein \n erwarte.
Vom Tablet hatte ich gesendet:
Anhang 32445
Richtig ist aber:
Anhang 32446
Damit klappt nun alles super schnell und ich bin happy.
Trotzdem danke für eure Hilfeversuche.
vG
fredyxx
Immerhin hat es sich bestätigt, dass es ursächlich nicht, wie ursprünglich von dir vermutet, am Empfänger/dem Arduino liegt, sondern Sender-seitig.
Dass es der Sender-Programmiercode war, ist sicher gut, da solche Fehler beseitigt werden können.
(y)
noch ein Hinweis zu der Klötzchen-Programmierung :
Diese bauen (fast) ausschließlich auf Interpretern auf, die einen mehr oder weniger vorverarbeiteten Zwischencode (oft Bytecode) erst noch während der Laufzeit in ausführbaren Code übersetzen müssen, bevor er dann ausgeführt werden kann.
Ich habe einmal verschiedene Benchmark-Tests zu diesen IDEs durchgeführt. Dabei hat sich bestätigt, dass viele(!) dieser Interpreter-Systeme (Klötzchen oder auch Text-Basiert) bis zu 100x langsamer sind als native Executables (per gcc oder clang).
Es gibt aber auch sehr viele Interpreter, die schlauer sind, z.B. der JIT-compiler ("Just-In-Time") von Java (C# Mono macht es ähnlich) - vereinfacht ausgedrückt: hier übersetzt der Compiler während des Interpreter-Betriebs häufig benutzte Teile des Codes in Executables, die dann genau so schnell sind wie C-compilierte executables.
Und tatsächlich haben Java-JIT- und C#-basierte Interpreter fast genaus so schnell abgeschnitten wie native Executables, wenn der Code öfter ausgeführt wurde - beim ersten Mal waren sie nur 1/10 so schnell.
Ältere oder einfachere Java-Compiler waren dagegen immer deutlich langsamer (1/20).
Gerade auf Androids laufen viele Apps per Java, auch mit JIT-Compilern.
Und gerade Klötzchen-Programmierung setzt ot auf Java auf, und daher kann es durchaus sein, dass nach ein paar Sekunden dein Klötzchen-Code schon ähnlich schnell ist wie "richtig" compilierter - dennoch muss man den Intepreter kennen bzw. testen, denn er kann möglicherweise auch dauerhaft z.B. nur 1/100 der erreichbaren Geschwindigkeit bringen.