[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?