I already reported that a few months ago that opening rar-archives definetely is much slower than ever before.
Today I noticed it extremly again opening a 1,8 GB archive including 1 file. It always takes 17 sec. to open in lister! The rar-plugin was set not to use unrar.dll. After I switched to it, it runs fast as always. So 7z.dll is the one slowing down things. Extracting is also noticable slower with it (testfile ~30 MB/s to ~130 MB/s).
Maybe useful: It doesn't matter if the archive includes 1000 or only 1 file, it's always slower than WinRAR or unrar.dll.
The disadvantage of unrar.dll is it does not report accurate timestamps as accurately as 7z.dll, and one or two similar issues. For me most RAR archives open instantly, but it probably depends how many files they contain or how they were made.
I'm a bit curious about this problem that Unrar.dll had. Could you explain more about it? I could possibly email them about the issue and see what they say about it. Who knows, they might actually fixed it and then we can all have fun decide which one to use depending on our mood that day haha. But yeah the performance for certain rar files is really bad especially for those that have amount of files and folders in them.
UnRAR.dll reports file times using the archaic MS-DOS time format, which is only accurate to a resolution of 2 seconds. (See RARHeaderDataEx.htm in the UnRAR documentation.)
The RAR format supports higher resolution timestamps but UnRAR.dll converts them into the old format.
Hmm yeah that is weird that their own dll does that when it could have kept the higher precise timestamps. I will shoot them an email and see if they reply.
Good news! The developers just replied! They said:
[quote]Hello,
It restores high precision timestamps when extracting and since nobody
asked us about reporting high precision timestamps, I thought that
DOS precision is enough for reporting.
Now I added the new build of UnRARDLL.exe to rarlab.com
It provides new MtimeLow, MtimeHigh, CtimeLow, CtimeHigh, AtimeLow,
AtimeHigh fields of RARHeaderDataEx structure, which are parts
of high precision FILETIME structure. Check RARHeaderDataEx.htm
and UnRDLL.c to see how to use them.[/quote]
Excellent! I've updated our code to use the new UnRar.dll and it seems to work great, and reports the timestamps correctly. We will make it the default again as I see no reason not to.
The change won't be in 12.2 (stable) as that is about to be released to fix some early issues, and I don't want to rush the change into that without a bit more testing. It will be in 12.2.1 (beta) which should be out fairly soon after that.
Of course, if you're eager to use UnRar.dll right now, you can switch to it via Preferences. All that will change in the forthcoming version is the default setting, and the more accurate timestamps when using it.
.