91–100 of 125 posts
"Finder (nee Archive Utility) should just execute the task without any visual feedback" -- no.
Earlier quoted context omitted.
That's highly unlikely. Archive Utility is just slow.
It's highly unlikely that it's 1000 times slower than the command line utility to decompress, with which they share the same libs anyway...
http://robservatory.com/postimages/unzipping/finder_v_termin...
Where do you think the people who wrote the thing that happens on the left inserted a gratuitous sleep?
Earlier quoted context omitted.
It's highly unlikely that it's 1000 times slower than the command line utility to decompress, with which they share the same libs anyway...
It isn't because they don't do anywhere close to the same thing. Watch the video: http://robservatory.com/postimages/unzipping/finder_v_termin... Where do you think the people who wrote the thing that happens on the left inserted a gratuitous sleep?
Windows explorer unzip is even worse. Recently in a VM I tried unzipping boost 1.62.0 using explorer in Windows 10. It said it would take over 3 hours. The same file was decompressed on the command line in about a minute using 7zip on the same VM.
For a tool that's supposed to be on most desktops by default, Explorer has some strange inefficiencies, such as the estimation and the loooong "preparing to copy" phase. Perhaps they are carried over from the old Windows NT codebase?
Windows explorer unzip is even worse. Recently in a VM I tried unzipping boost 1.62.0 using explorer in Windows 10. It said it would take over 3 hours. The same file was decompressed on the command line in about a minute using 7zip on the same VM.
Windows also always unzips to a fixed scratch directory before creating the real files. That scratch directory is %TMP% or %TEMP%, I think, but it definitely always is on the same disk, typically C: If you unzip files to another disk than where that directory lives, it unzips to its scratch directory, then _copies_ the extracted files to their destination, and finally deletes the scratch files. That's bad in itself,…
I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…
Just want to add, `unzip` from your terminal window can be used as well. If opening those gz's every month is a pain, you could handle it with something like: `unzip -r my_stuff_{1..99}.zip`
Earlier quoted context omitted.
It isn't because they don't do anywhere close to the same thing. Watch the video: http://robservatory.com/postimages/unzipping/finder_v_termin... Where do you think the people who wrote the thing that happens on the left inserted a gratuitous sleep?
For each file, a split second to animate the apparition of the window (or the increase of the existing window), another split second to show the empty progress bar, a millisecond to fork the decompression process, a couple of frames at 60 Hz to animate it being filled, and another split second to animate the disappearance of the window (or the decrease of the existing window).