[Jiaz]

Originally Posted by mensa

Welche denn? Warum warst du so lange weg von hier?

Fehler bei HTTP Proxies, Recaptcha Stuff, HCaptcha Stuff, Emails/Tickets/Support und daily Work.

[B1gD4ddy]

Originally Posted by pspzockerscene

Ja.

Originally Posted by Jiaz

@B1gD4ddy: Ja, aber derzeit finde ich leider einfach wieder genug Zeit das weiter zu planen, da gerade andere Dinge meine Zeit fressen

oki thx

[mensa]

Gibt es für Windows 10 x64 eigentlich mittlerweile eine neuere Version als die 1509?
Mir kommt diese leider ziemlich langsam vor beim Entpacken.

[Jiaz]

@mensa: definiere mal bitte *kommt leider ziemlich langsam vor* ?
Von/auf gleiche Platte/SSD/Netzlaufwerk? Mal ein paar Infos. An der Entpackergeschwindigkeit wird sich auch mit neueren Versionen nicht viel ändern, da auch hier der gleiche original unrar Code zum Einsatz kommt.

[mensa]

Ok, ich werd es beim nächsten Download stoppen, ob es tatsächlich einen Unterschied zwischen 7zip und JDownloader gibt. Sollte eigentlich keinen geben, oder?

[Jiaz]

Du kannst auch ohne Download jederzeit ein Archiv via JDownloader entpacken über die Fensterleiste-Tools und dort dann ein Archiv auswählen und entpacken. Zb also selbst was packen und dann Zeit nehmen

[mensa]

Danke. Sollte es gleich schnell sein wie 7zip?

[mensa]

Also mein Gefühl hat mich nicht getäuscht!

Habs jetzt mal mit einem 10 GB ZIP File getestet, welche 1 MKV enthält und verglichen. Entpackt wird jeweils auf die lokale SSD:

7zip: 9,5 Sekunden
JDownloader: 17 Sekunden

Das ist mehr als 70 % langsamer und bei größeren Archiven dann schon extrem spürbar. Warum ist da so ein extremer Unterschied?

[Jiaz]

Versuch mal Einstellungen->Profieinstellungen->MaxBufferSize auf zb 4096 zu stellen
JDownloader danach neustarten
Und würde mich freuen ob das Auswirkungen auf die Geschwindigkeit hat, danke schonmal!

[mensa]

Mit dieser Einstellung ist es sogar noch schlechter geworden (22 Sekunden).

Soll ich es wieder auf den ursprünglichen wert ändern? Leider weiß ich den nicht mehr genau. 500?

[pspzockerscene]

Rechts ist ein kleiner gelber Pfeil der setzt zurück auf den Standardwert und ja dieser ist 500.

Grüße, psp

[mensa]

Danke!
Jemand eine Idee, warum JDownloader so graviernd langsamer ist beim Entpacken?

Wird da evtl. kein Multithreading verwendet und bei 7zip aber schon? Oder kein "x64" oder irgendwas in die Richtung?

Das Problem ist ja nicht so schlimm, aber interessant wäre schon, warum das denn so ist.

[Jiaz]

Du entpackst von SSD auf SSD? Mit größerem Buffer darf es nicht schlechter werden. Stell mal auf 8192. Default ist 512. Die Zeiten kannst nicht "direkt" vergleichen, da 7zip den Buffer nicht flasht, während JDownloader aber schon, sprich bei JDownloader sind nach dem Entpacken die Daten auch auf der Platte. Welche SSD hast du denn? Denn 9,5 Sekunden wären mehr als 2Gbyte/s IO Dauerleistung

[mensa]

Originally Posted by Jiaz

Du entpackst von SSD auf SSD?

Ja.

Mit größerem Buffer darf es nicht schlechter werden.

Es ist aber so. Ich hab das jetzt mehrmals getestet.

Stell mal auf 8192.

Damit wird es noch langsamer -> 28 Sekunden!

Default ist 512.

Bei mir wird als Default 500 vorgeschlagen. Was stimmt jetzt?

Die Zeiten kannst nicht "direkt" vergleichen, da 7zip den Buffer nicht flasht, während JDownloader aber schon, sprich bei JDownloader sind nach dem Entpacken die Daten auch auf der Platte.

Wenn ich den PC sofort nach dem Entpacken mit 7zip stromlos mache ist die entpackte Datei nach dem Neustart trotzdem vollständig und fehlerfrei auf der Festplatte.

Welche SSD hast du denn? Denn 9,5 Sekunden wären mehr als 2Gbyte/s IO Dauerleistung

Ich hab eine NVMe SSD (Samsung SSD 970 Evo Plus 1TB), das passt also schon, die kann mit bis zu 3.500 MB/s lesen und bis zu 3.300 MB/s schreiben.

[Jiaz]

@mensa: Können wir uns das mal gemeinsam via Teamviewer anschauen? Ich hatte in meinen Tests nie einen großen Unterschied feststellen können und bei Nutzern wo das war, lag es meist an Firewall/AV die da Speedunterschiede verursacht hat. Auch wundert mich das der größere Buffer hier eher nachteilig ist,obwohl er das Gegenteil sorgen sollte. Gemeinsam können wir dann auch mal eine neuere Lib testen. Ist dein JDownloader 32 oder 64 bit? Findest die Info im About Dialog

[Jiaz]

Kannst mir an support@jdownloader.org oder jiaz@jdownloader.org schreiben

[mensa]

Originally Posted by Jiaz

Ist dein JDownloader 32 oder 64 bit? Findest die Info im About Dialog

Meinst du damit die Java Version? Seh nämlich nur in der Zeile Java etwas bezüglich 64 Bit:

Java: Oracle Corporation - Java(TM) SE Runtime Environment - 1.8.0_40(64Bit)

Oder soll da von JDownloader selbst auch noch wo was stehen?

Bzgl. Teamviewer ist es grad ein bisschen schlecht.

[Jiaz]

@mensa: ist 64bit, von daher passts. Hättest du denn die Woche mal für Teamviewer Zeit?

[mensa]

Ehrlich gesagt möchte ich niemanden per TeamViewer auf diesen Rechner lassen.
Können wir das vielleicht auch irgendwie anders lösen?

[Jiaz]

@mensa: du kannst auch gerne so die neuste ausprobieren, siehe
sourceforge.net/projects/sevenzipjbind/files/7-Zip-JBinding/16.02-2.01/
du musst die Dateien so umbennen, dass diese wie die existierenden Dateien heissen, also mit dem 1509 im Namen

[mensa]

Danke, ich werde das am Abend oder morgen mal probieren.

Ich habe inzwischen das ganze auf einem anderen PC nochmal getestet. SSD dort ist: Samsung SSD 850 EVO 500 GB. Das Zip war ca. 7,5 GB groß.

Entpacken mit 7zip: 83 Sekunden
Enptacken mit JDownloader: 107 Sekunden

Erhöhen der MaxBufferSize brachte keine Verschlechterung, aber auch keine Verbesserung.

Ist also kein lokales Problem und müsste einfach nachgestellt werden können.

[raztoki]

@mensa

with your current test its ~29% slower.

I assume you have the cpu priority advanced setting to high? settings > advanced settings > Extraction.cpupriority

problem as I see it, JD has little control over how slow the extraction event is, support is based on its external library. The external library will extract as fast as its code permits (and your system). The only influence JD has is interactions, like preventing extraction of specific items: filename based ignore and sub directory like rules. This could slow down extraction a little. It's not as simple task as external program that just extracts everything without the same check and balances. The only way to really compare if its the library is at fault would be use the external library directly (outside of JD) to perform exact same task, and making sure the same parameters (buffers, on disk checks) are performed by both sides. Then you could determine the exact influence JDownloader extraction extension has and also the library.

raztoki

[mensa]

Originally Posted by Jiaz

@mensa: du kannst auch gerne so die neuste ausprobieren, siehe
sourceforge.net/projects/sevenzipjbind/files/7-Zip-JBinding/16.02-2.01/
du musst die Dateien so umbennen, dass diese wie die existierenden Dateien heissen, also mit dem 1509 im Namen

Danke, das Verhalten hat sich dadurch aber leider gar nicht verändert.

[mensa]

Originally Posted by raztoki

with your current test its ~29% slower.

On that PC yes, on the other nearly 80% slower with JD vs. 7zip.

I don't know what exactly I could do or test further now

[raztoki]

@mensa well if you want to isolate fault you need todo the tests I mentioned in my previous post.

On your other system, it could be the hardware? differences in 7zip versions, probably other variables in play

[mensa]

Sorry, but I don't understand how to do that tests.

Why could it be the hardware? JDownloader and 7zip are running on the same hardware.
7zip version is everywhere the 19.00 x64. I don't think that checking anything in 7zip or on my hardware will lead to faster JDownloader extractions.

I think it will lead to the target if JDownloader devs will check that problem in JDownloader as it could be reproduced on other PCs also easily.

[raztoki]

@mensa some cpu architecture are better at crypting/decrypting & compressing/decompressing (two seperate issues) than others.

Assuming you did the same test on two different systems, yet results are vastly different. It could be part of the reason for the large disparity.

[mensa]

The problem is, that on same systems JDownloader is extracting 30% - 80% slower than 7zip!! So there are no different cpu architectures used!!

[Jiaz]

Originally Posted by mensa

Why could it be the hardware? JDownloader and 7zip are running on the same hardware.
7zip version is everywhere the 19.00 x64.

@mena: 7zip may optionally use hardware features while the 7zip binding might be compiled with more generic feature set. They share the same code but there are still differences like compiler settings/enabled features/7zip for example supports multithreading 7z extraction while the binding doesn't (as far as I know) and most important. 7zip runs completely native while the bindung runs in Java(Read+Write) and Native(Extraction) which of course may impact performance.

What compression format did you use for testing? Then I will create test archives for myself.

Please test the newest version from link I gave you. Other than that there is not much we can do about different performance.

[mensa]

I tried with ZIP, but seems the same with RAR.

I already tried the files from your link, but did not change anything.

Maybe that information would have helped one day ago, where I mentioned, that JD is extracting much slower. Then we all would have saved a lot of time wasted for nothing.

[Jiaz]

@mensa: It is important that you rename the files first, you can check the version in Settings->Archive Extractor. Yes, that information about archive format is important because I was talking about RAR only all the time

[mensa]

RAR is the same, not measured in seconds, but also much slower.

I renamed the files correctly.

[mensa]

Hier jetzt die Test-Ergebnisse mit RAR Archiven -> es verhaltet sich so ziemlich ident. JDownloader braucht hier leider auch rund doppelt so lange :(


RAR: 7,66 GB auf Samsung SSD 970 Evo Plus 1TB:

7Zip: 9,5 Sekunden

JDownloader (7Zip Binding Version: 15.09-2.01beta)
Max Buffer Size: 500: 19,5 Sekunden
Max Buffer Size: 8192: 22,5 Sekunden

JDownloader (7Zip Binding Version: 16.02-2.01)
Max Buffer Size: 500: 17,5 Sekunden
Max Buffer Size: 8192: 21,5 Sekunden

[Jiaz]

@mensa: Ich werde ein paar Tests unter Linux/Windows machen.
Könntest du mal via Taskmanager die CPU Last von JD/7Zip während dem Entpacken vergleichen? Evtl kann hier 7zip mehrere Kernen fürs Entpacken nutzen, was sich an der CPU Last sofort zeigen dürfte.

Hier mein erstes Ergebnis:
-Linux, 64Bit, Samsung SSD, 500 Buffer Größe, 12.5GB RAR-> JDownloader=1:23 Min, Unrar=1:18 Min

[mensa]

Ich hab mal so gut wie möglich alles geschlossen und dann den Taskmanager beim Entpacken mitlaufen lassen. Die CPU Auslastung war bei JDownloader sogar gefühlt höher!

[mensa]

Wie man hier sehen kann, verwenden aber sowohl 7Zip als auch JDownloader alle Cores:

[Jiaz]

Auch mal in der Prozesse Liste schauen während dem Entpacker. Evtl funkt beim JDownloader Entpacken ja irgendein Tool/Firewall/AV dazwischen?
Einstellungen->Profieinstellungen->Extraction.cpupriority steht auf High, richtig?

[mensa]

Ich habe kein Tool, keine Firewall und keinen AV installiert.
Priority ist auf High.
Problem läßt sich sehr einfach auf anderen Rechnern nachstellen. Also sicher nichts lokales.

[Jiaz]

Ich konnte es leider nicht lokal nachstellen (Tests auf Windows stehen noch aus)

[mensa]

Auf welcher SSD?