Pausen nach z.B. anklicken eines Downloads

[Gucky]

Hallo,
seit der Version 13.5.1 passiert etwas “Neues” nicht so “Nettes”.
Immer, wenn ich per Mausklick einen Download starte, kann ich für eine spürbare Zeit ( 10 Sekunden + x ) keine weiteren Aktionen durch anklicken starten. ( D.h. weiteren Download starten oder auch löschen eines Films aus der Favoritenliste.)
Das war - meine ich - früher nicht so.
Auch nutzt die Mediathekview.exe relativ viel CPU Leitung … beim Laden eines Films gerade überwiegend 25%, beim Starten eines Downloads aber auch “locker” einige bis zu 50%.
Ist das “normal” ?
War das bei den vorherigen Versionen auch so und ich habe es nur nicht gemerkt ?

MfG, “Gucky”

[iks-jott]

Von MediathekviewWeb nach hier verschoben.

[Ein ehemaliger Benutzer]

@Gucky sagte in Pausen nach z.B. anklicken eines Downloads:

Auch nutzt die Mediathekview.exe relativ viel CPU Leitung … beim Laden eines Films gerade überwiegend 25%, beim Starten eines Downloads aber auch “locker” einige bis zu 50%.

@DerReisende77 Ich habe bei mir mal nach sehr sehr kurzer Suche nach einem gratis Profiler für Java VisualVM installiert und einfach mal den CPU Profiler auf MV (src develop von heute) losgelassen.

Ich habe mal in einer völlig anderen Anwendung in einer anderen Programmiersprache den Ladevorgang großer Dateien dadurch beschleunigen können, indem ich nicht alle paar Byte eine Fortschrittsmeldung abgesetzt habe, sondern die Anzahl der Fortschrittsmeldungen -im damaligen Fall- auf 100 Stück begrenzt hatte.

Meinerseits zwei Ja-Nein Fragen:

1. könnte es sein, dass ein nennenswerter Teil der CPU Last bei MV Downloads vom Fortschrittsbalken-Mechanismus verwendet wird?
2. und ggfs. vom Bremsen des Downloads auf die maximal freigegebene Download-Bandbreite?

Ich gebe zu, ich habe mich nicht in den Code eingelesen - vor dem Wochenende komme ich auf keinen Fall dazu.
Vielleicht schau ich mal rein und spiele ein wenig an der Stelle.

edit:
zu 1) auf den ersten Blick bin ich mir noch nicht sicher, was dieser Profiler mit TimeUnit…sleep(500) macht.
zu 2) das mit den 1000 Updates (je Zehntelprozent) wäre mit dem Zähler p beinahe gegeben. Aber wie oft “melden=true” gesetzt wird wegen geänderter Bandbreite zum vorherigen Schleifendurchlauf… werd ich mir mal anschauen.

[DerReisende77]

@Gucky was für einen Rechner ( CPU, RAM,etc) und welches Betriebssystem nutzt Du?

[DerReisende77]

@rubikon
zu 1.: ist eigentlich nicht zu erwarten und auch in deinem Trace nicht zu sehen
zu 2.: ja, das throttlen braucht ein wenig CPU power, das ist auch bei dir sichtbar. Je mehr DL parallel laufen desto mehr CPU wird dafür verbraucht da alle Theads beim Allokierer anfragen müssen. Dies lässt sich aber auch nicht verhindern.

Beides hat aber mit dem OP nicht wirklich viel zu tun da er den Hänger von 10sek+ beim Start des DL hat. Hier würde die Vermutung erst mal in Richtung besch**enes Netz gehen.

Die 50% CPU Last sind “relativ”. Da nicht bekannt ob dual core oder octacore usw kann man keine verlässliche Aussage hierzu geben. Von daher könnte es normal sein. Auf meinem Octacore wäre 25% CPU Auslastung über alle Kerne es definitiv nicht. Bei einem Dual core system definitiv ja. Dort kommen schliesslich auch noch neben dem DL, der (von den usern gewünschten) Fortschrittsanzeige im Windowsfenster auch die notwendigen Updates des UI hinzu welche mit JavaFX via OpenGL generiert werden. Also kommt nun auch noch eine Grafikkarte in die Gleichung hinzu.

Erst wenn man alle Parameter kennt kann also eine halbwegs plausible Antwort versucht werden zu finden.

Wo Du die TimeUnit.sleep(500) im Bild entdeckt hast habe ich nicht gefunden. Der TaskbarIndicatorThread schläft aber nach einem Update 500ms um danach wieder zu aktualisieren. Der gesamte Prozess ist nur auf einer echt lahmen Kiste cpulastig, ansonsten merkt man dies nicht. Eine längere Schlafphase ist aber nicht drin da sonst der Taskbar progress in windows asynchron läuft zum ende hin.

[Ein ehemaliger Benutzer]

@DerReisende77 ich hatte genau den von Dir erwähnten 500ms im TaskbarIndicatorThread gemeint.
Was mir mangels Kenntnis der Bibliotheken beim bloßen Lesen/Überfliegen des Codes von downloadContent verdächtig vorkam war das “melden = true” bei geänderter Bandbreite.

Habe eben kurz eine kleine Statistikausgabe machen lassen. In meinem Beispiel wurden in 2:35 Minuten

• 547 Aufrufe wegen “nächstes Zehntelprozent erreicht”
• 156 Aufrufe wegen “Bandbreite geändert”

abgesetzt für so ~2-3 GB Download. Also ca. 1x GUI refresh pro Sekunde angefordert vom Download wg. Bandbreite. -
Ich hatte gestern bei meinem Post nach dem (Anfänger-)Blick auf den Profiler um mehrere Größenordnungen andere Zahlen befürchtet. Aber das sieht -nach Stichprobengröße 1…- doch gut aus, nach einem gesunden Maß an Updatehäufigkeit.

Der Rechner, mit dem ich diese 1 Messung gemacht habe, ist mein uralter i7 (4 Kerne mit jeweils HT) Desktop von … 2010?
Meine Internetanbindung ist mittelprächtig, 200 MBit/s downstream.

[Gucky]

@DerReisende77
ich habe eine Intel 2400S 4-Kern CPU (schon was älter aber schnell genug) und benutze Win 10 Pro.
[vor der neuesten Version waren die Probleme (meine ich) nicht da.)