10.2 Finder Still Slow
My BBEdit Backups folder is open in a list view sorted by date. I select 4957 items and type Command-Delete to move them to the trash. The Finder locks up with the larger and even more brightly colored spinning pizza of death—for 45 minutes. This is on an 800 MHz G4 with no other load except for iTunes. I put the files back in the folder and rebooted into OS 9 to see how fast it was. In 9, moving the same files to trash took 57 seconds. Add about four minutes to account for the two reboots, and that is still nine times faster than the OS X Finder. Please don’t anyone tell me that I need to optimize my hard drive or buy more RAM, that the Finder is new code, that I should use Column view, that I should know not to put so many files in one folder, that I should have used rm *, or that isn’t it great that iTunes didn’t skip while this was going on.4 Comments RSS · Twitter
Your example would carry more weight if it was a real world example. Yes, I know that there are times when you need to trash that many things, but you didn't need to here, you just did it to point out a problem. Problem exists, fine, but don't act like you had to wait 45 minutes the other day. if productivity is so important, why are you wasting so much time to point out that the Finder sucks?
And don't dismiss % rm. The finder does have problems, but there are work arounds in the interim. It's your own fault if you refuse to use what you know is there.
Not bitching about your gripes, as we know the Finder needs work, but its become pathological, man!
This was a real world problem. It's something that I actually wanted to do, and I didn't know beforehand that it would be so slow.
As it turns out, rm * doesn't work with that many files. So you have to rm them in batches, or know fancy shell tricks. I'm not actually sure how to do this with xargs because many of the file names contain spaces.
I've tried to copy thousands of files from a Windows server volume to my local disk and have experienced the beach ball. These were all good real world circumstances. I usually got it if I made the mistake of using my mac while the copy was happening, but I've gotten it even when I've left the computer untouched after starting the copy. I didn't even know I could wait 45 minutes and expect my Mac to snap out of it. And the terminal isn't a good fallback: cp, CpMac, rsync, that hfs version of rsync, and even tar all segfaulted on the same group of files. I suspect something wrong at the kernel level, but what the hell do I know? I'm an anonymous coward.
If it were 10.1 Finder, you'd end up waiting for a couple of hours ;) Does it makes you feel any better?
But yeah, something has to be done. Perhaps a haxie that will speed up move to trash operations in the Finder (as I am not hoping Apple will get their act together and fix it before next major OS update)?
=)