[eridius]

I've been using Yosemite since the early betas and it's been great for me. I don't use Photoshop, and I can certainly believe that Adobe might be doing nasty things, but all the apps I do use have been fine.

> really long pauses anytime I try to save a simple document for the first time

Is that actually what's happening, or is it a really long pause when trying to show the open/save dialog? I have a couple of NAS volumes mounted, and if I run an app with a Recent Documents entry that lives on one of the volumes, and the NAS is asleep, then the app will often pause when trying to populate the Recent Documents list. This normally happens during open/save. Previous versions of OS X did it too, though I feel like Yosemite might trigger it a bit more often for some reason.

[prawn]

No, really long time to save after actually hitting the Save button. Something to do with creating a new file maybe?

On Friday when I went to reboot, after coming back up it spun overnight without finishing the boot. That started a process which took three days to get Internet Recovery working, restore from Time Machine and then upgrade to Yosemite and finally ditch that awful beta. Absolute waste of time and when I could least afford it.

The long saving times and visual glitches have disappeared with the full Yosemite by the way. Phew!

[pmjordan]

I've seen this behaviour, too. Could it be worse in Yosemite if you have iCloud Drive enabled? Of course, Apple ought to listen to their own advice of "never do I/O on the main thread" but then they don't bother with sandboxing their own App Store apps, either.

[eridius]

I haven't tried iCloud Drive, though that should not be related as, assuming it works anything like iDisk did, it would keep the drive local and sync changes back and forth, rather than doing direct network loading/saving.

As for I/O, last time I checked, the Recent Documents list is actually being loaded on a background thread, but the main thread is where the UI for it has to be populated. Normally the list would be loaded before the main thread goes to access it, but when the load is blocked by e.g. my NAS waking up, the main thread ends up waiting on a semaphore.

It is rather unfortunate, since nothing I'm doing actually needs to see the recent documents list. And if you're going to say that the main thread should be able to simply indicate that it's still loading, and refresh the list when the load finishes, then I completely agree. But I would not be surprised to find that the relevant code here is many years old, possibly written in C, with no maintainers, and not having been touched in those many years, so there's probably little chance of it being fixed :/