d60Dave

Q: Slow file open dialogue box

Hi,

 

I upgraded to Mavericks OS over the weekend and everything seems to work ok. The only thing I have noticed is that my when I try to attach a file in Mail the dialogue box opens and where previously files would immediately appear they now take several seconds, maybe as long as five, ten seconds.

 

I think I've noticed similar behaviour in other applications but Mail is the one I use the most in this way.

 

Has anyone else experienced this since upgrading to Mavericks?

 

 

Regards and thanks,

 

Dave.

MacBook Pro (15-inch, Mid 2012), OS X Mountain Lion (10.8.2)

Posted on Oct 28, 2013 6:03 AM

Close

Q: Slow file open dialogue box

  • All replies
  • Helpful answers

Previous Page 2 of 14 last Next
  • by ADeweyan,

    ADeweyan ADeweyan Nov 15, 2013 12:10 PM in response to d60Dave
    Level 1 (0 points)
    Nov 15, 2013 12:10 PM in response to d60Dave

    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.

  • by d60Dave,

    d60Dave d60Dave Nov 15, 2013 12:14 PM in response to St. Clair Software
    Level 1 (10 points)
    Nov 15, 2013 12:14 PM in response to St. Clair Software

    I'm not running Default Folder X and I am experiencing delays.

  • by brilor,

    brilor brilor Nov 15, 2013 1:01 PM in response to St. Clair Software
    Level 1 (20 points)
    Nov 15, 2013 1:01 PM in response to St. Clair Software

    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

  • by St. Clair Software,

    St. Clair Software St. Clair Software Nov 15, 2013 1:16 PM in response to brilor
    Level 1 (5 points)
    Nov 15, 2013 1:16 PM in response to brilor

    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.

  • by brilor,

    brilor brilor Nov 15, 2013 2:29 PM in response to St. Clair Software
    Level 1 (20 points)
    Nov 15, 2013 2:29 PM in response to St. Clair Software

    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

  • by atpyburn,

    atpyburn atpyburn Nov 15, 2013 8:08 PM in response to St. Clair Software
    Level 1 (0 points)
    Nov 15, 2013 8:08 PM in response to St. Clair Software

    Not using this program either, but the info about reseting the behavior and it having to do with metadata is interesting.

  • by LaloY.,

    LaloY. LaloY. Nov 16, 2013 2:06 PM in response to d60Dave
    Level 1 (0 points)
    Nov 16, 2013 2:06 PM in response to d60Dave

    Same problem since installed Mavericks... i tried everything...also NOT SHARING in SHARING control panel...any posibility to send people in APPLE this problem so they try to fix this issue¿¿

  • by Posthumous ,

    Posthumous Posthumous Nov 16, 2013 4:43 PM in response to LaloY.
    Level 2 (235 points)
    Nov 16, 2013 4:43 PM in response to LaloY.

    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.

  • by LaloY.,

    LaloY. LaloY. Nov 16, 2013 5:00 PM in response to Posthumous
    Level 1 (0 points)
    Nov 16, 2013 5:00 PM in response to Posthumous

    I think that we can only wait an apple update for Mavericks solving the issue...

  • by gs_mac,

    gs_mac gs_mac Nov 17, 2013 5:55 AM in response to Posthumous
    Level 1 (0 points)
    Nov 17, 2013 5:55 AM in response to Posthumous

    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.

  • by brilor,

    brilor brilor Nov 17, 2013 7:35 AM in response to gs_mac
    Level 1 (20 points)
    Nov 17, 2013 7:35 AM in response to gs_mac

    gs_mac wrote:

     

    Just adding a "me too".

    Thanks gs_mac.

     

    I would also encourage all the "me too"s out there to REPORT THIS TO APPLE. More reporters means higher priority.

     

    The Apple Feedback link is here

     

    Apple BugReporter is here.

  • by jflow,

    jflow jflow Nov 17, 2013 4:24 PM in response to d60Dave
    Level 1 (5 points)
    Nov 17, 2013 4:24 PM in response to d60Dave

    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. 

  • by St. Clair Software,

    St. Clair Software St. Clair Software Nov 17, 2013 8:51 PM in response to jflow
    Level 1 (5 points)
    Nov 17, 2013 8:51 PM in response to jflow

    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.

  • by brilor,

    brilor brilor Nov 17, 2013 10:56 PM in response to jflow
    Level 1 (20 points)
    Nov 17, 2013 10:56 PM in response to jflow

    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.

  • by brilor,

    brilor brilor Nov 17, 2013 11:02 PM in response to brilor
    Level 1 (20 points)
    Nov 17, 2013 11:02 PM in response to brilor

    brilor wrote:

     

    I would also encourage all the "me too"s out there to REPORT THIS TO APPLE. More reporters means higher priority.

     

    The Apple Feedback link is here

     

    Apple BugReporter is here.

    btw: Please file Apple Feedback. Apple is NOT watching these posts, so the "me too" posts do NOT inform Apple. I'm sure Apple's developers can barely keep up with reported bugs.

Previous Page 2 of 14 last Next