BeanShell - Textdatei auslesen

[Sheldon2012]

Der TV-Browser ist gierig, wie immer 336 MB.
Er wird ja mit einer VM gestartet, die a-priori 320 MB von mir erhält.
Das habe wir vor langer Zeit mal besprochen.

Die Testdatei kann man ganz einfach erstellen.

Ich nehme den String

dummy;dummy

und kopiere den im Notepad.

Natürlich zuerst einen 10-Block.
Dann kopiert man den 10 mal 10-Block.
Dann kopiert man den 10 mal 100-Block.
Dann kopiert man den 10 mal 1000-Block.

Und an den Schluss setzt Du, damit er auch was findet:

Die Rosenheim-Cops;Ein Abgang mit Blubb
Die Rosenheim-Cops;Zu Tode gesteigert
Die Rosenheim-Cops;Tot im Netz
Um Himmels Willen;Bloßgestellt
Um Himmels Willen;Miss Kaltenthal
Falling Skies;Eine dunkle Nacht
Gotham;Arkham

[ds10]

Das bringt aber nichts, denn 10000 Mal dummy;dummy macht in der HashMap exakt einen Eintrag aus. Mit deinen weiteren Einträgen sind dann 5 Werte in der HashMap gespeichert und wie zu erwarten, wird das Ergebnis, bei Anwendung des Filters auf die Programmtabelle, sofort gezeigt.

[Sheldon2012]

Schau dir mal die Tabelle der Lieblingssendungen an.
Übrigens werden merh sendungen angezeigt als in der Datei sind.
z.B bei Rosenheim-Cops, Um himmels willen

[ds10]

Ich habe nur 96 Lieblingssendungen und natürlich wird der Filter dort auch ohne Verzögerung angewendet. In der alten Version hätten die 10000 dummy-Einträge allerdings schon zur Verzögerung geführt. In der neuen können sie es aber nicht, da sie eben zu nur einem Eintrag reduziert werden.

Und da TV-Browser eine Filterkomponente genau einmal zu Beginn einliest, liegen nach dem Start alle Daten im Speicher vor. Ein Vergleich auf fünf Datensätzen stellt für Java nun wirklich kein Problem dar und dabei darf es nicht zu einer Verzögerung kommen.

Ich weiß ja nicht, wie dein Filter konstruiert ist, aber vielleicht ist irgendwo eine Endlosschleife entstanden und die würde TV-Browser auf jeden Fall in die Knie zwingen (insbesondere das Plugin Filter-Filterkomponente sollte man vorsichtig einsetzen).

[ds10]

Fehlerhaft gefundene Sendungen/nicht gefundene Sendungen lassen sich übrigens leicht erklären, du hast getID() für das Speichern des Status für eine Sendung benutzt, die gibt aber nur eine ID zurück, die für einen Tag eindeutig ist, an anderen Tagen kann die wieder auftreten. Ich habe das mal zu getUniqueID() geändert, die ist für jede Sendung eindeutig, auch an unterschiedlichen Tagen:

CSVFileFilterComponent.jar

(8.6 KiB) 84-mal heruntergeladen

[Sheldon2012]

Erst aml danke für die Korrektur der ID. Das passt jetzt. Das mit der Eindeutigekeit pro Tag hatte ich auch gelesen, aber die UniqueID habe ich wohl übersehen.

Da hat es wohl meine Testumgebung des TV-Browsers zerissen. Ich bin jetzt mal auf ein Backup zurückgesprungen.
Da klappt es. Keine Performanceprobleme.

Du hast natürlich recht. Die Einträge müssen unterschiedlich sein. Das teste ich als nächstes.
Ich melde mich dann wieder.

Nochmal vielen, vielen Dank für Deine Hilfe.

[Sheldon2012]

Ich habe jetzt mal eine Datei erzeugt

dummyN;dummyN mit N = 1....10000
Als nächstes mache ich dann mal einen Test mit echten Daten.

[ds10]

Das überrascht mich jetzt nicht. Die Technik mit HashMap und HashSet ist schon eine sehr starke Optimierung. Vermutlich würden auch 100.000 Einträge kein Problem bereiten. Allerdings wäre es wenig wahrscheinlich dass die eingelesenen Daten genauso groß wären, da du für Serien sicher mehrere Folgen einträgst und die reduzieren sich, pro Serie, zu einem Eintrag in der HashMap, die Folgen befinden sich ja dann, pro Serie, in einem HashSet.

[Sheldon2012]

Realistisch ist eine durchschnittliche Anzahl von 200 Episoden pro Serie. Das ist eigentiich schon recht hoch gegriffen.
Gehen wir mal von einer Mediathek mit 500 Serien aus. Das ist schon einges.
Dann hätten wir 500 HashMap-Einträge mit je einem HashSet mit maximal 200 Einträgen und 100.000 Einträge im CSV-File.
Da muss man erst mal hinkommen. Ich teste mal.

[ds10]

In deinem Beispiel hättest du selbst bei Verwendung einer normalen Map und Listen nur einen Aufwand von maximal 700 Operationen pro Sendung, mit den gehashten Variablen sind es noch viel weniger (wahrscheinlich nicht einmal ein Aufwand von 50 pro Sendung). Im Vergleich zur alten Lösung verschwindend gering, denn dort hättest du pro Sendung einen Aufwand von maximal 100.000. Bei 500 zu prüfenden Sendungen wäre das ein Aufwand von 50 Million in der alten Lösung zu 350.000 in einer Lösung mit Map und Listen.

Man kann daher davon ausgehen, dass selbst eine Datei mit 1 Millionen Einträgen mit der neuen Lösung noch problemlos von TV-Browser verarbeitet werden kann. Und um auf eine Millionen Einträge zu kommen, muss man sich echt anstrengen. (Also täglich 100 neue Einträge für 30 Jahre, dann hat man gut eine Millionen zusammen.)

[Sheldon2012]

Ja, ja! Da hätte man schon ein ganze Menge zu gucken!

Ich habe überlegt, ob es sinnvoll sei, auf der Basis der aktuellen Lösung (HashMapSet) auch ein BeanShell-Sktipt als Optimierung zu erstellen und im Wiki zu präsentieren. Die finale Optimierung wäre dan die separate Komponente.
die könnte man ja dort auch aufführen. Wahrscheinlich ist die Komponente zu speziell, um sie als offizielles Plugin zu präsentieren, oder? Dann hätte man die komplette Bandbreite abgedeckt und es wäre für den genegten Leser sicher verständlicher.

Was war noch einmal der entscheidende Vorteil der separaten Komponente?

Ach ja, wie machst Du die Pfade relativ? Das wäre noch sinnvoll.

Übrigens will der TV-Browser neuerdings immer die gleichen Plugins aupdaten.
Ich lasse ihn dann machen, aber beim nächsten mal meldet er sich erneut.
Was ist denn da los?

[ds10]

Ich finde jetzt nicht, dass man das nicht als Plugin veröffentlichen sollte. Der Vorteil des Plugins liegt ja gerade darin, dass es für einen Benutzer sehr viel einfacher ist, als einen Beanshell-Filter zu erstellen. Melde dich einfach im Entwickler-Bereich an und lade dann dort deine Filterkomponente hoch.

Der Beanshell-Filter ist außerdem sehr beschränkt, du kannst alles nur aus der accept-Methode heraus machen und die kann durchaus mehrfach gleichzeitig aufgerufen werden, wenn du also dort die Daten nur einmal laden willst, musst du einige Verrenkungen machen, damit das richtig funktioniert und trotzdem performant bleibt.

Da du eine nicht-stabile Version von TV-Browser verwendest, wirst du immer die Updates für die Plugins im Beta-Zustand erhalten (auch wenn sich an denen gar nichts geändert hat).

[Sheldon2012]

Kann man den Pfad relativ machen?

Derzeit gehe ich ja von einer Serie aus, bei der es Episoden gibt.
Abstrakt betrachtet ist ja ein Film oder eine Dokumentation auch eien "Serie". Sie hat halt genau eine Episode, nämlich sich selbst (episode=title). Das könnte man ja noch berücksichtigen. Da gibt es doch im ProgramInfoHelper das Feld categorie_series. Das könnte man doch abfragen, um zu erfahren, ob program zu einer serie gehört. Hast Du da vielleicht ein Beispiel? So könnte man auch Filme, Dokumentationen usw. mit diesem Ansatz abdecken.

[ds10]

Relative Pfade kann man mit IOUtilities.checkForRelativePath(String path) und IOUtilities.translateRelativePath(String path) einbauen (jeweils beim Speichern und Laden des Pfades angewendet).

Um eine Kategorie zu prüfen, kann man ProgramInfoHelper.bitSet(int num, int pattern) benutzen. (num enthält die kodierten Kategorien einer Sendung und pattern, die zu prüfende Kategory im Fall einer Serie Program.INFO_CATEGORIE_SERIES)

[Sheldon2012]

Also so?

if (ProgramInfoHelper.bitSet(1, program.INFO_CATEGORIE_SERIES){
program ist serie
}