Ok, I have been using Vista for a couple of weeks now, and I have noticed it is quite slow at extracting .zip files, but this is ridiculous!

 

Yes, they are both extracting the same .zip file. In the time it took for the Vista extractor (upper window) to get this far, I was able to re-download the file, save it to my desktop and begin the extraction with 7zip (lower window).

The 7zip extraction completed approximately the specified time. I cancelled the Vista extractor after 7zip finished.

WTF is Vista doing that makes it take over 75 times longer than 7zip?!
 

Very strange indeed.  I can't see the interface being THAT slow.  It does remind me of the main gripe I have with new interfaces (not windows specific).  It's really nice to estimate the time it's going to take to perform a file operation, but if the time it takes to estimate the time that it's going to take is longer than the time itself, then don't bother.  For instance, it can take like 5 seconds to delete a couple files. 4 seconds of it is scanning those files to estimate how long it's going to take, 0.99s drawing the little window with the animations, and 0.01s doing the actual deleting.  It's just a simple file system unlink... nothing complicated.  But people like these pretty animated GUIs telling them what's going on, and I guess that's the way it's going to be.  Oh well, I'll go back to my cmd line and carry on like nothing ever happened (thank $DEITY for cygwin)

/rant 

I guess Microsoft figures that if they make zip extraction take long enough, then most users will stop downloading zip files containing malware/virii/spyware and the like.... thus yet another "Security Feature" of Vista! Go Microsoft!

Odd.  I've used Vista's built-in unzip many times, but never had any speed issues with it.  I guess your mileage may vary.

I always had the same problem with XP's built in extractor.  I don't know why.

skippy:

Very strange indeed.  I can't see the interface being THAT slow.  It does remind me of the main gripe I have with new interfaces (not windows specific).  It's really nice to estimate the time it's going to take to perform a file operation, but if the time it takes to estimate the time that it's going to take is longer than the time itself, then don't bother.  For instance, it can take like 5 seconds to delete a couple files. 4 seconds of it is scanning those files to estimate how long it's going to take, 0.99s drawing the little window with the animations, and 0.01s doing the actual deleting.  It's just a simple file system unlink... nothing complicated.  But people like these pretty animated GUIs telling them what's going on, and I guess that's the way it's going to be.  Oh well, I'll go back to my cmd line and carry on like nothing ever happened (thank $DEITY for cygwin)

/rant 

There was a DailyWTF post (I won't bother searching for it because just the gist is good enough) where the submitter's customer was convinced the software wasn't working because it just went too damn fast. He had to add code to slow it down as well as put in unnecessary GUIs to give the customer that warm fuzzy. Makes you wonder how much of Microsoft's technologies operate on this principle.

XP's extraction is also a lot slower than 7zip/winzip/winrar/a monkey manually typing in hex codes. This is impressively evident with a lot of small files in a zip. 200MB of files up to about 10kb each and often around 2-3kb took 4 hours under XP's extractor and about 10 mins at most in 7zip.

Manni:

There was a DailyWTF post (I won't bother searching for it because just the gist is good enough) where the submitter's customer was convinced the software wasn't working because it just went too damn fast. He had to add code to slow it down as well as put in unnecessary GUIs to give the customer that warm fuzzy. Makes you wonder how much of Microsoft's technologies operate on this principle.

I remember that one, and I've had to deal with issues like that in the past.  Of course it's nice when a client thinks it's too fast, so you slow it down, then they decide it's now too slow, so you charge them extra to "optimize" it for them.  Silly clients :P
 

mallard:

WTF is Vista doing that makes it take over 75 times longer than 7zip?!

Re-implementing unzip from scratch is the problem. It's probably the same code as the painfully slow XP implementation.

It's probably caused by the same NIH mentality that led to the horrible support for PNG images in IE6, even though libpng is free (and well tested).

Correct me if I'm wrong, but doesn't every unzipping program (including Windows) use the same basic code (zlib) underneath it all?  I have found that browsing a zipped file and trying to copy its contents somewhere is much slower than right-clicking and selecting "extract".

maybe your YKK.dll is corrupt :D

 

(don't get this?... look at the nearest zipper) 

Cap'n Steve:

Correct me if I'm wrong, but doesn't every unzipping program (including Windows) use the same basic code (zlib) underneath it all? I have found that browsing a zipped file and trying to copy its contents somewhere is much slower than right-clicking and selecting "extract".

In the built-in Windows zip implementation, copying files out of a zip archive does the following:

 - create a temporary directory somewhere (I think it's your user-temporary location, which is usually inside your profile)

 - extract the relevant files into that directory

 - copy or move the files from that directory to the place where you dragged them

 - delete the temporary directory

Yes, this is slower than extracting the files directly to the target location.
 

skippy:

Very strange indeed.  I can't see the interface being THAT slow.  It does remind me of the main gripe I have with new interfaces (not windows specific).  It's really nice to estimate the time it's going to take to perform a file operation, but if the time it takes to estimate the time that it's going to take is longer than the time itself, then don't bother.  For instance, it can take like 5 seconds to delete a couple files. 4 seconds of it is scanning those files to estimate how long it's going to take, 0.99s drawing the little window with the animations, and 0.01s doing the actual deleting.  It's just a simple file system unlink... nothing complicated.  But people like these pretty animated GUIs telling them what's going on, and I guess that's the way it's going to be.  Oh well, I'll go back to my cmd line and carry on like nothing ever happened (thank $DEITY for cygwin)

/rant 

Actually, walking the folder tree and reading the file attributes would take nearly the same amount of time whether it was done upfront or during the deletion. Locations and information gets cached, and the actual delete can be overlapped. Overall it's a bit of a wash, via command-line a little faster. You could load up VM sessions and time how long it takes to remove the same path via GUI and via command-line.

Hi!

I contacted WinZip about the slow extracting of zip files under Vista, and they told me to right click the Zip-file and choose Properties and then Unblock before extracting it. And that seems to do the trick, at least for me. A little more hassle than before, but still livable…

Take care!
Svein

asuffield:

In the built-in Windows zip implementation, copying files out of a zip archive does the following:

This seems to be S.O.P for most archive extractors I've seen in Windows. Everything gets extracted into %TEMP% (with bonus random subdir that usually doesn't get removed after completing), no matter where you're extracting to. Rar's particularly stupid in this regard. I have to go clean out the temp dirs every few days to kill off all the stray rar leftovers.

The whole "extract to local temp dirs" is especially painful when you're using network drives with large-ish archives.

MarcB:

asuffield:

In the built-in Windows zip implementation, copying files out of a zip archive does the following:

This seems to be S.O.P for most archive extractors I've seen in Windows. Everything gets extracted into %TEMP% (with bonus random subdir that usually doesn't get removed after completing), no matter where you're extracting to.

It's a misfeature of Windows itself. This will happen any time you perform a "copy" operation from within an application to an explorer window.

I've been using Vista for several months, and have never noticed it until this past week. Maybe it's some update that Microsoft has put out? Unzipping a 3 MB zip file takes 10 minutes??? WTF Microsoft!

Back when I lived on campus and the CS department still hosted Linux isos, I once downloaded a full 700MB iso in under two minutes.  Windows then merrily copied the ISO out of the temp directory onto the desktop.  It took nearly ten minutes (go go laptop hard drive!).

 I fail to see what possesses MS to write behaviour like that into the OS.

 

Heron:

Back when I lived on campus and the CS department still hosted Linux isos, I once downloaded a full 700MB iso in under two minutes.  Windows then merrily copied the ISO out of the temp directory onto the desktop.  It took nearly ten minutes (go go laptop hard drive!).

 I fail to see what possesses MS to write behaviour like that into the OS.

 

Who knows?  They used to have an amazingly problematic limitation of only being able to copy files of size n where n = your total RAM.  Otherwise you get an out of memory error.  Best part?  It didn't just tell you this before hand.  It dies when it's 80% through and you're screaming "Why couldn't you have told me that in the first place so I didn't waste 5 minutes!?"  Obviously that limitation is long gone now :)

But the copy & paste / zip slowness is addressed in Vista SP1, thank god: http://windowsvistablog.com/blogs/windowsvista/pages/windows-vista-service-pack-1-beta-whitepaper.aspx

Right now I use a 3rd party app to do basic OS functionality :-\

ShadowWolf:

Right now I use a 3rd party app to do basic OS functionality :-\

What app?

As for programs using the temp directory wtf is up with that. When I was running windows 98 I had two physical drives, a 500MB C: drive which hosted windows (which took up ~250MB) and a 2.1GB Secondary HDD. Every 5 hours of uptime I would have to purge the temp directory which I explicitly altered the registry for because my C drive was suddenly full. Then I would have to explore to find the other magical places POS software decided to shit in and clean that out. By the end of the two years I did this my C: drive seemed to lose space (not additional windows components installed, nothing installed to C: during that time) and I had less and less temp space and more and more frequent temp purging. Also note I did defrag frequently.

Lingerance:

ShadowWolf:

Right now I use a 3rd party app to do basic OS functionality :-\

What app?

As for programs using the temp directory wtf is up with that. When I was running windows 98 I had two physical drives, a 500MB C: drive which hosted windows (which took up ~250MB) and a 2.1GB Secondary HDD. Every 5 hours of uptime I would have to purge the temp directory which I explicitly altered the registry for because my C drive was suddenly full. Then I would have to explore to find the other magical places POS software decided to shit in and clean that out. By the end of the two years I did this my C: drive seemed to lose space (not additional windows components installed, nothing installed to C: during that time) and I had less and less temp space and more and more frequent temp purging. Also note I did defrag frequently.

That magically decreasing free space sounds more like a dying drive than temp file cruft (you're running out of good sectors to map on the disk), but I suppose any programs that frequently create a large number of temporary files (e.g., your basic web browsing fare) are bound to exacerbate problems with a flaky drive. Defragging doesn't help since it'll just create large contiguous blocks of the available free space, not reclaim legitimately bad sectors.

sootzoo:

Lingerance:

ShadowWolf:

Right now I use a 3rd party app to do basic OS functionality :-\

What app?

As for programs using the temp directory wtf is up with that. When I was running windows 98 I had two physical drives, a 500MB C: drive which hosted windows (which took up ~250MB) and a 2.1GB Secondary HDD. Every 5 hours of uptime I would have to purge the temp directory which I explicitly altered the registry for because my C drive was suddenly full. Then I would have to explore to find the other magical places POS software decided to shit in and clean that out. By the end of the two years I did this my C: drive seemed to lose space (not additional windows components installed, nothing installed to C: during that time) and I had less and less temp space and more and more frequent temp purging. Also note I did defrag frequently.

That magically decreasing free space sounds more like a dying drive than temp file cruft

No, this is win98, so it's running on a FAT filesystem. It is safe to assume that the FAT driver was just slowly losing track of disk blocks - scandisk was not desperately good at locating and correcting errors, and the driver was notoriously unsafe. You pretty much wanted to restore a disk image every six months or so.

I've always had trouble with the slow XP unzip. For me it's always been hundreds of times too slow. It used to crash Explorer a lot, too. (I guess I was too lazy to change the file association.)

Last night I installed Vista, but only because all my XP licenses are in use on my other computers. I had horrible multi-monitor trouble with Vista in the past and already gave up on it once. So the first thing I did on the fresh Vista install was grab a 40MB .zip from a network share... and TRY to unzip it.

Big mistake.

After about 30 seconds I notice that it's STILL working and I look at the window. My jaw drops in horror and I feel my whole body tense up. I'm staring at something like:

"Unzipping file.zip (8 bytes)"

I proceed to watch it SLOWLY, OH SO SLOWLY count up from there: ".......11 bytes...............16 bytes..................22 bytes......."

I click the cancel button harder than I've ever clicked anything in my life (at 28 bytes) while literally saying out loud, "Ooooooooh-KAYYYYYY-thennnn."

Then I ran to the Internet to get 7-zip. 7-zip took about five seconds to unzip the file.

 I joined just to add to thi.

I extracted SugarCRM (or, tried to) using Windows Extractor, it didn't finish and took over 24 hours.

 I downloaded 7zip and it took 3.5 minutes.

Hoaobrook:

 I joined just to add to thi.

I extracted SugarCRM (or, tried to) using Windows Extractor, it didn't finish and took over 24 hours.

 I downloaded 7zip and it took 3.5 minutes.

OMG I JUST REGISTERED TO SAY ME 2!

Hoaobrook:

 I joined just to add to thi.

I extracted SugarCRM (or, tried to) using Windows Extractor, it didn't finish and took over 24 hours.

 I downloaded 7zip and it took 3.5 minutes.

 

 

 
RISE FROM YOUR GRAVE!