Nein. Der Maker ruckelt nicht weil er zwischen Events hin- und herschalten muss. Jedenfalls nicht im Normalfall. Wenn zu viele performanceträchtige Befehle hintereinander ausgeführt werden müssen (wie z.B. Show Picture), dann braucht der Maker logischerweise länger um diese Befehle zu verarbeiten. Ergo kann er den Befehl nicht schnell genug zuende bearbeiten und zum nächsten Event schalten. Da trotzdem alles in seinen geordneten Wegen laufen muss, werden die Befehle trotzdem weiter bearbeitet. Es dauert nun länger bis "normal" weiter gearbeitet werden kann. Und halt auch bis zum nächsten Befehl umgeschaltet wird. Und schon bemerkst du diese Arbeit. Eben als Verzögerung.Zitat von CapSeb
Das es für dich so lange dauert, liegt an deiner Messmethode.
Die für so etwas simpel nicht geeignet ist. Die einzige wirklich ernst zunehmende Möglichkeit um so etwas zu messen, ist es ein zweites Programm nebenbei mitlaufen zu lassen. Dieser kann dann genau im internen messen wie lange die Anwendung für bestimmte Vorgänge benötigt. Aber bestimmt nicht dadurch das du solche Messungen versuchst im Programm selbst vorzunehmen.
Bei den makerinternen Dingen wie bspw. den Bewegungsgeschwindigkeiten geht das wunderbar. Aber nicht bei so etwas. Das sieht man ja an deinen Messergebnissen.
Wie schon gesagt, es gibt ohne einen zweiten CPU Kern der andere Befehle bearbeiten kann kein echtes paralleles arbeiten. Das wird vom PC nur vorgetäuscht. An sich eher vom OS um genauer zu werden. Wenn dich diese Thematik so interessiert, dann solltest du dich einmal mit der Thread programmierung auseinandersetzen. Da erfährst du mehr über dieses Prinzip.Aber schonmal gut zu wissen, dass er springt.
An sich aber brauchst du so etwas nicht wirklich für den Maker imo.
Da reicht an sich das grobe Wissen das parallele Prozesse "gleichzeitig"
arbeiten. Und natürlich wie die Eventaktivierung von statten geht.
Wer so etwas versteht, wird mit dem ganzen Eventsystem kein Problem haben.
Zitieren