Slow extraction of nsis exe's

I noticed slow extraction of nsis exe's, so I compared uniextract v1.5 vs cmdtotal instexpl.wcx. I obtained cmdtotal and instexpl from uniextract's bin directory.

In both cases, I used the same machine (Athlon 2000+ 512MB RAM Windows Server 2003 sp2 R2) to extract the same nsis exe: privoxy_setup_3_0_6.exe (474kB, http://sourceforge.net/project/showfiles.php?group_id=11118). Runtimes were benchmarked with MS ntimer.exe.

Trial 1 command: ntimer cmdtotal.exe instexpl.wcx x privoxy_setup_3_0_6.exe temp
Trial 1 results (sec): ETime 0:00:00.530 UTime 0:00:00.280 KTime 0:00:00.140 ITime 0:00:00.070

Trial 2 command: ntimer uniextract.exe privoxy_setup_3_0_6.exe temp
Trial 2 results (sec): ETime 0:00:06.879 UTime 0:00:00.570 KTime 0:00:00.200 ITime 0:00:01.191

As you can see, cmdtotal took 0.53 sec while uniextract took 6.879 sec to extract the same nsis exe! Why does uniextract extract so slowly?

Of course, uniextract must first identify privoxy as nsis before extracting (via cmdtotal instexpl.wcx). Running cmdtotal instexpl.wcx directly (i.e. without uniextract) bypasses this identification step and thus must be faster. But does this identification step completely explain the measured difference in speed (0.53 vs 6.879 sec)?

I can't give you a definite answer without actually testing this myself, but there are two difference between calling UniExtract and calling cmdTotal directly that could add to the total time:

  1. UniExtract must identify the filetype (as you pointed out). Normally this doesn't take too long, but depending on how easily (or not) the file is recognized it could certainly take a few seconds. If an .exe file is not identified right away with TrID, it's then run scanned with PEiD up to three times (three different scans) until a match is found. If still no match is found, it's blindly tested with 7-Zip, InfoZip, and I think cmdTotal. If it's not extracted until that last blind fallback check, then yeah, 6 seconds is a reasonable estimate of scan time.
  2. 7-Zip is used by default for NSIS extraction, with cmdTotal used as a fallback option. If 7-Zip is being used in this case, it's possible that it extract the files more slowly then cmdTotal. Six seconds is rather significant in this case though, so I'm more inclined to think it's due to the first issue.

Like I said, all this is off the top of my head without being able to do any actual testing. I'll be back on a Windows system within the next day or two and can look into this further if need be. In the meantime, I'd suggest rerunning the test with UniExtract and reading through the status messages. Does it display several status messages before it actually begins extraction? Eg, something like "Scanning file to determine filetype", plus "Scanning file with xxx scan" multiple times? If so, then the delay is almost certainly with the scanning and detection rather than actual extraction.

--
http://www.legroom.net/

Add new comment

Filtered HTML

  • Allowed HTML tags: <a href hreflang> <acronym> <blockquote cite> <br> <cite> <code> <dd> <div> <dl> <dt> <em> <img src alt title height width> <li> <ol start type> <p> <pre> <span> <strong> <sub> <sup> <ul type>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.