Performance-Probleme

[asrael]

Hi,

ich zitiere hier mal aus folgendem Beitrag (viewtopic.php?p=159510#p159510):

[quote=""ascaris""]
Ich habe auch mal die Filer 2.0 Beta4 ausprobiert aber habe seitdem das problem, dass Kanalzapping danach erheblich länger dauert. Wenn ich mit P+/P- die Kanäle hoch/runter zappe dauert es nach dem ersten zappenb ca. 3-4 Sekunden bis der nächste Kanal kommt.,

Auch dauert die EPG Anzeige in der InfoBox (ImproBox) erheblich länger. Das dann immer wieder, egal ob rauf oder runter oder vor/zurück.[/quote]

Nachdem ich bislang noch nie größere Probleme mit der Filer-Performance hatte, habe ich am Wochenende intensiv mit der TAP-Startreihenfolge herumgespielt und dabei (mit geladener Improbox und einer Menge anderer TAPs) die gleichen Erfahrungen wie ascaris gemacht.

Weitere Tests ergaben folgendes: wird filer relativ spät gestartet (also z. B. nach improbox), ergab sich genau oben beschriebenes Verhalten. Wird filer relativ früh gestartet (bei mir aber nach nicedisplay und fastskip), läuft alles recht normal.

Da relativ viele von Euch ja Probleme mit der Performance haben, die elle nicht nachvollziehen kann, lohnt sich vielleicht mal ein Umstellen der Startreihenfolge. Insbesondere wenn filer manuell nachgestartet wird und schon einige TAPs laufen, ist er ja das letzte TAP und es ergibt sich bei mir auch wieder obiges Verhalten.

@elle und firebird: Ist es möglich, dass filer, als letztes gestartet, den anderen TAPs nicht genügend Idle-Events übriglässt? Am Anfang von TAP_EventHandler findet sich

Code: Alles auswählen

  //FireBird 2007-01-03: Wenn kurz zuvor eine Taste gedrückt wurde (100ms), nur mehr Key_Events durchlassen
  if ((event != EVT_KEY) && (TAP_GetTick() < KeyEventLock)) return 0;

Unter bestimmten Umständen kann also ein Idle-Event von Filer für 100 ms verschluckt werden. Liegt es vielleicht daran (nur so eine Idee, ohne mich wirklich mit Eurem Code näher beschäftigt zu haben)?

mfg

asrael

[ibbi]

Kann man IDLE-Events mit return 0 blocken?

[asrael]

[quote=""ibbi""]Kann man IDLE-Events mit return 0 blocken?[/quote]

Tja, ich weiß es nicht genau. Aber eigentlich sollte man events ja weitergeben (es sei denn, man hat sie verarbeitet und möchte sie abfangen (vor allem Tastatur-Events)).

Aber bei einem Idle-Event will ich doch den anderen TAPs die Gelegenheit geben, auch was zu machen und deswegen würde ich denken: in jedem Fall

Code: Alles auswählen

return param1;

.

Ich bin mir da aber nicht sicher, man müsste mal ein TAP schreiben, das einfach alle idle events schluckt und dann schauen, ob andere TAPs noch was machen können.

Bin aber gerade im Büro und daher nicht kopf- aber Topf-los.

mfg

asrael

[FireBird]

[quote=""asrael""] Insbesondere wenn filer manuell nachgestartet wird und schon einige TAPs laufen, ist er ja das letzte TAP und es ergibt sich bei mir auch wieder obiges Verhalten.

@elle und firebird: Ist es möglich, dass filer, als letztes gestartet, den anderen TAPs nicht genügend Idle-Events übriglässt? Am Anfang von TAP_EventHandler findet sich

Code: Alles auswählen

  //FireBird 2007-01-03: Wenn kurz zuvor eine Taste gedrückt wurde (100ms), nur mehr Key_Events durchlassen
 

[/quote]

Der Reihe nach: bei mir steht der Filer im AutoStart weit hinten und beim Testen wird er sowieso oft manuell nachgestartet. Aber ich werde mal im MemWatcher die wirkliche Position in der Tabelle beobachten.

Genügend Idle-Events gibt es nicht. Sobald die Firmware-TAPIdle-Routine aufgerufen wird, prüft sie in einer Schleife alle 16 Einträge der TAP-Tabelle auf geladene TAPs und ruft die TAP_EventHandler auf. Wie lange es dauert bis die Kontrolle wieder an die Firmware zurückgegeben wird und somit das nächste TAP aufgerufen wird, hängt nur vom gerade aktiven TAP ab.

Der Grund für meine Abfrage ist ein anderer: im Idle-Event werden vom Filer mehrere Aufgaben erledigt, z.B. das Blinken der Icons, Checks wegen der DB u.s.w. Diese benötigte Zeit produziert regelmäßige Hänger beim Scrollen. Deshalb sperre ich die Abarbeitung der Idle-Jobs nachdem eine Taste gerückt wurde.

[quote=""ibbi""]Kann man IDLE-Events mit return 0 blocken?[/quote]
Laut Firmware wird der Return-Code nicht ausgewertet.

[asrael]

[quote=""FireBird""]Der Reihe nach: bei mir steht der Filer im AutoStart weit hinten und beim Testen wird er sowieso oft manuell nachgestartet. Aber ich werde mal im MemWatcher die wirkliche Position in der Tabelle beobachten.

Genügend Idle-Events gibt es nicht. Sobald die Firmware-TAPIdle-Routine aufgerufen wird, prüft sie in einer Schleife alle 16 Einträge der TAP-Tabelle auf geladene TAPs und ruft die TAP_EventHandler auf. Wie lange es dauert bis die Kontrolle wieder an die Firmware zurückgegeben wird und somit das nächste TAP aufgerufen wird, hängt nur vom gerade aktiven TAP ab.

Der Grund für meine Abfrage ist ein anderer: im Idle-Event werden vom Filer mehrere Aufgaben erledigt, z.B. das Blinken der Icons, Checks wegen der DB u.s.w. Diese benötigte Zeit produziert regelmäßige Hänger beim Scrollen. Deshalb sperre ich die Abarbeitung der Idle-Jobs nachdem eine Taste gerückt wurde.


Laut Firmware wird der Return-Code nicht ausgewertet.[/quote]

OK, waren meine Vermutungen also falsch. Aber die Beobachtung "Filer hinten in Startreihenfolge = zähes Verhalten beim Kanalwechsel und lange Zeit, bis Improbox EPG-Infos anzeigt" erhalte ich aufrecht

Ich habe das ganze übrigens mehrmals getestet, sowohl über Autostart als auch über manuellen Start aller 13-14 TAPs: Filer als ca. drittes = kein Problem, Filer als letztes = Problem.

mfg

asrael

[ibbi]

[quote=""FireBird""]Laut Firmware wird der Return-Code nicht ausgewertet.[/quote]

Das hatte ich gehofft.

Trotzdem gefiele mir return param1 auch besser (ebenso übrigens wie TAP_GenerateEvent(EVT_KEY, RKEY_wasweißich, 0)), aber das ist Geschmackssache.

[FireBird]

[quote=""asrael""]Aber die Beobachtung "Filer hinten in Startreihenfolge = zähes Verhalten beim Kanalwechsel und lange Zeit, bis Improbox EPG-Infos anzeigt" erhalte ich aufrecht [/quote]
Vielleicht kenne ich die schnelle Version noch gar nicht. :

[ibbi]

[quote=""asrael""]Filer als letztes = Problem[/quote]

Kommt nicht das letzte TAP auch als letztes dran? Soll heißen: Es sollten dann doch eher die anderen TAPs (bzw. Wechselwirkungen zwischen diesen und Filer) Schuld sein, und nicht der Filer, der als letzter ja gar nichts machen kann (außer von den Hunden gebissen zu werden).

[asrael]

[quote=""ibbi""]Kommt nicht das letzte TAP auch als letztes dran? Soll heißen: Es sollten dann doch eher die anderen TAPs (bzw. Wechselwirkungen zwischen diesen und Filer) Schuld sein, und nicht der Filer, der als letzter ja gar nichts machen kann (außer von den Hunden gebissen zu werden).[/quote]

Ja, bei Key-Konflikten sehe ich das auch so (erstes TAP schluckt aus Versehen irgendeine Taste, die dann das zweite TAP gar nicht mehr erreicht). Bei den Idle-Events könnte aber doch auch das letzte TAP sagen wir mal pro Idle-Event 3 Sekunden Bremse spielen und damit dann auch die vorher gestarteten TAPs ausbremsen, da die Firmware ja nur noch sehr sporadisch die Kontrolle erhält.

mfg

asrael

[FireBird]

[quote=""ibbi""]Kommt nicht das letzte TAP auch als letztes dran? [/quote]
Man muß nur aufpassen, daß sich in der Zwischenzeit kein anderes TAP beendet hat und der Filer sich auf dessen Platz weiter vorne in die Queue drängt.

[asrael]

[quote=""FireBird""]Man muß nur aufpassen, daß sich in der Zwischenzeit kein anderes TAP beendet hat und der Filer sich auf dessen Platz weiter vorne in die Queue drängt.[/quote]

??? Worauf bezieht sich das?

EDIT: Gerade fehlte aber noch das Zitat, oder?

[FireBird]

Ja, das habe ich nacheditiert nachdem Du Dich dazwischengemogelt hast.

[asrael]

[quote=""FireBird""]Ja, das habe ich nacheditiert nachdem Du Dich dazwischengemogelt hast.[/quote]

ops: ops: ops:

Und trotzdem denke ich, dass auch ein als letztes gestartetes TAP, das den IdleEvent "missbraucht" andere TAPs ausbremsen könnte, oder?

Was aber nicht heißen soll, dass Filer das macht.

mfg

asrael

[FireBird]

Wie gesagt, alle Events sind kooperativ.

[ibbi]

[quote=""FireBird""]Wie gesagt, alle Events sind kooperativ.[/quote]

Da haben sie machen TAPs einiges voraus. :

[Elle4u]

[quote=""FireBird""]Der Grund für meine Abfrage ist ein anderer: im Idle-Event werden vom Filer mehrere Aufgaben erledigt, z.B. das Blinken der Icons, Checks wegen der DB u.s.w. Diese benötigte Zeit produziert regelmäßige Hänger beim Scrollen. Deshalb sperre ich die Abarbeitung der Idle-Jobs nachdem eine Taste gerückt wurde.[/quote]
Das könnten wir aber in den Teil

Code: Alles auswählen

  if (FilerShow)

schieben, oder?

Außerhalb interessiert es uns ja nicht...

[FireBird]

[quote=""Elle4u""]Das könnten wir aber in den Teil

Code: Alles auswählen

  if (FilerShow)

schieben, oder?[/quote]Wenn es Dir dort besser gefällt...


[quote=""ibbi""]Trotzdem gefiele mir return param1 auch besser.[/quote]
Da fällt mir noch etwas ein, habe ich aber noch nicht ausprobiert. Eigentlich returniert man nicht param1 sondern einen bool-Wert. Solange !=0 bekommt das nächste TAP den KeyCode. Beim Idle-Event ist es ja egal (zumindest mir).

[ibbi]

[quote=""FireBird""]Da fällt mir noch etwas ein, habe ich aber noch nicht ausprobiert. Eigentlich returniert man nicht param1 sondern einen bool-Wert.[/quote]

Seit wann? Der Return-Wert des Event-Handlers ist dword.

[FireBird]

[quote=""ibbi""]Seit wann? Der Return-Wert des Event-Handlers ist dword. [/quote]
Was kann ich dafür. Aber probier es mal aus. Das kam von bdb von simonc aus UK.

[asrael]

[quote=""FireBird""]Was kann ich dafür. Aber probier es mal aus. Das kam von bdb von simonc aus UK.[/quote]

Also, um klar zu sehen: In der API-Doku steht ja, man soll param1 zurückgeben. Ich habe mir bisher immer gedacht, dass damit der Keycode an die anderen TAPs weitergegeben wird (die dann die Ereignisart selbst aber auf firmware-magische Art und Weise bekommen) und man so auch die gedrückte Taste prinzipiell verfälschen könnte.

Ich meine, schon gesehen und auch selbst benutzt zu haben:

Code: Alles auswählen

return RKEY_NoUse;

um andere TAPs von irgendeiner Weiterverarbeitung abzuhalten (und RKEY_NoUse ist gleich 0x1000d, also definitiv ungleich 0).

Und Du sagst jetzt, dass hier von der Firmware lediglich 0 oder 1 unterschieden würde? Sicher?

mfg

asrael