Slow file open dialogue box

****, this is frustrating. i'm having the exact same issue.

2012 macbook pro 9,1 2.3GHz quadcore 16GB ram 240GB SSD

no reason for anything to ever take 20 seconds or more to load.

trashed .plist, repaired permissions, nothing.

not sure where to go but i've got a few experiments i'm gonna run.

hope we get to the bottom of this soon.

Anyone solved this issue. I am going mental here. I probably lose about an hour of working time a day because of this and am starting to drink far too much coffee as a result... (***Medical Bill in the post to Apple***).

Do Apple read this forum? We need an updated version pronto

Same here: frustratingly slow population of dialog boxes in all applications. Competely slows down normal work flow. (MacBook Pro early 2011, 256 Gb SSF Samsung, 750 Gb HD in former opitical drive bay.

Hoping Apple will fix this problem soon.

Having the same issue here. Haven't been able to consistently reproduce. But it is happening is several different apps. I am running a 2011 13" Macbook with an SSD. Will update if I am able to narrow this down any more.

I'm the author of Default Folder X - an enhancment for Open and Save dialogs - and have been fielding reports from my users complaining of this same problem in Mavericks, asking if my software's causing it. Are you folks running Default Folder X, or are you experiencing the same delays without it?

I've done a bunch of performance testing and cannot for the life of me get Default Folder X to cause any additional delays - however, I'm seeing some fairly long waits with Mavericks on its own, and want to confirm that you folks are seeing the same thing.

For what it's worth, it seems to happen for some folders the first time you access them, but after their metadata gets into the disk cache, response is almost instantaneous. If you experiment with a folder on an external disk drive, you'll find that unmounting (ie. ejecting) the drive and then remounting it will reset this behavior and the first access to the folder will be slow again.

Just adding my voice...

I'm running on a 2012 model iMac with Fusion drive. Quick file access was one of the key reasons I sprung for the Fusion drive, and this is driving me nuts. I'll wait 10+ seconds before any files show in Open dialogues.

St. Clair Software wrote:

(1) Are you folks running Default Folder X?

(2) For what it's worth, it seems to happen for some folders the first time you access them

(1) No DFX here and AFAIK nothng else calling beginSheetModalForWindow: on behalf of another app but the issue persists.

(2) Yes, once the metadata is cached, subsequent "Open...."s populate normally

FWIW: A simple Cocoa Xcode5 project running a simple modal NSOpenPanel exhibits the same behavior:

Try this in a default Cocoa project:

/////////////

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {

NSOpenPanel* op = [NSOpenPanel openPanel];

if ( [op runModal] == NSOKButton )

NSLog(@"%@",[op URL] );

}

/////////////

Best Regards,

Brian Stevens, BrilorSoftware

Yup - and if you actually check out what's going on with Instruments, there's a whole lot of file access from the internal TNode classes as they pull in all the file and folder properties. When that I/O has to go to the disk instead of the cache, it takes quite a while. One point of interest: the "Size" column in list view now shows the total sizes of folders - so when the Finder or a file dialog shows the contents of a folder, it's actually recursively getting the size of every file and folder within it. This is done in the background, so the listing isn't stuck until it finishes adding everything up, but it does generate a lot of extra disk I/O.

St. Clair Software wrote:

Yup - and if you actually check out what's going on with Instruments, there's a whole lot of file access from the internal TNode classes as they pull in all the file and folder properties.

Yep, I can see all the FinderKit calls in a File Activity stack trace. I'm going to update my rdar ( 15437435 ) to include that earlier code snippet.

BTW: noticed console error messages ( which I've already posted in the rdar ) about failed assertions for open/close panel

1/13/13 2:03:34.177 PM com.apple.appkit.xpc.openAndSavePanelService[375]: assertion failed: 13A603: liblaunch.dylib + 25164 [FCBF0A02-0B06-3F97-9248-5062A9DEB32C]: 0x25

Thanks for chiming in.

Brian

I tried everything too and nothing works.

2013 27" iMac. Came with 10.8 and it was great. Upgraded to 10.9 and 20-25 seconds of spinning gear before import/open/place files appear in any app.

Has anyone done a clean install of Mavericks bypassing the upgrade route. Rumor has it that will fix it. I have a couple of friends with new MBP that came with Mavericks and they're fine.

Just adding a "me too". I have no experience of clean Mavericks installs, here I've upgraded my Mac Pro which was still running Snow Leopard while I'm waiting to upgrade the Macbook Pro, currently running Mountain Lion, until these teething problems will be solved.

Not related to:

1) Clean install of Mavericks - I performed a clean install of Mavericks on a 2010 iMac as well as on a 2011 13" Macbook Pro. Having the issue on both.

2) Related to Defualt Folder X - nope several people have reported that this is not installed on their system, including myself

Might be related to:

1) SSD drives - It seems several people have complained about this being an issue when they have a fusion drive. I don't have a fusion drive, but my Macbook pro has an SSD and the iMac has one of the Seagate Hybrid drives.

2) a caching bug - St. Clair Softwareand brilor pointed this out. And I aggree because when I access the folder the first time it is slow, but then subsequent times it is practically instantanious. Has anyone tried what brilor has suggested in Xcode? When I try disconnecting and reconnecting an external drive I am not able to consistently reproduce these delays.

3) related to a piece of software we have installed and running in the background - A few that might possibly be culprits: dropbox, iStat Menus, DriveGenius 3, RescueTime, 1password

comment - I would encourage the "me too"s to help figure out how to consistently reproduce the issue accross multiple machines. Apple won't give a hoot if they can't reproduce the issue. And based on this thread being relatively slow, I don't think we are going to get the kind of attention required for them to start troubleshooting this themselves. I expect this is related to a piece of software we have installed.

To be clear - the caching issue isn't a bug, it's the way caching works. As a matter of fact, this shows that the disk caching system in OS X actually works pretty well - the file dialogs are slow when none of the file information is cached, but once you've accessed the info on disk once, it stays in the cache and then file listings are much faster.

jflow wrote:

1) Clean install of Mavericks - I performed a clean install of Mavericks on a 2010 iMac as well as on a 2011 13" Macbook Pro. Having the issue on both.

Might be related to:

2) SSD drives - It seems several people have complained about this being an issue when they have a fusion drive. I don't have a fusion drive, but my Macbook pro has an SSD and the iMac has one of the Seagate Hybrid drives.

3) a caching bug - St. Clair Softwareand brilor pointed this out. And I aggree because when I access the folder the first time it is slow, but then subsequent times it is practically instantanious. Has anyone tried what brilor has suggested in Xcode? When I try disconnecting and reconnecting an external drive I am not able to consistently reproduce these delays.

4) related to a piece of software we have installed and running in the background - A few that might possibly be culprits: dropbox, iStat Menus, DriveGenius 3, RescueTime, 1password

(1) thanks for the confirmation. Hadn't tried that yet.

(2) No SSD here, only 2 TB HDD

(3) Ditto St. Clair's response.

My small sample program just tries to rule out other code by writing code that only calls the open file dialog. It is not meant as a solution. the point is: if it fails just with that code, it should limit where to look. I posted this to Apple too. Instruments stacktraces indicate lots of activity in Apple code while the open dialog waits for file population. I'm hoping Apple will contact me on my open rdar and request more debugging info.

(4) No startups here. All launch daemons removed from /Library/LaunchDaemons including one each for Drive Genius and TextWrangler and problem persists.

Thank you! Thank you! Thank you! Thank you! Thank you! Thank you!

This bug was like some sort of Chinese water torture. The irritation just built and built. I thought I was going to go nuts. I spend so much time working with photographic and audio files. All the things I have tried including the last resort in-place reinstall of OS X 10.9 when I had given up and as requested by the so-called experts in AppleCare support which led to more problems that I had to fix and still had this one annoying Open/Save/Export/Import dialog issue. I had assumed it had something to do with the messages I was seeing written for "com.apple.appkit.xpc.openAndSavePanelService" and was at a complete loss and had decided to give up and hope, wish, wait for Apple to release a fix in a one-off.

Now, more than one month later, your workaround worked and you are my hero today, Snaggletooth_DE ➕

P.S. This type of issue is the very reason I have always waited until the first update (10.x.1) was available and Mavericks has taught me how wise such waiting was.