[Greg Jones]

I'm curious if others have long load times (15-20 seconds) when loading OmniFocus on Lion? I've struggled with this for months now, even sent a report to the ninjas, but they responded at the time they haven't seen any reports on this. I have tried pruning my database, archiving old entries, rebuilding the database, yet nothing has helped. I'll get a long delay at launch, the app beach balls, and then everything is fine. I can quit the app, restart it a few minutes later, and the load time is nearly instant. However, if I wait an hour or so, the long load time is back.

I got so fed up with this that I decided yesterday to wipe my hard drive clean and reinstall Lion. I did not restore anything on the drive from Time Machine-just a clean install of Lion and OmniFocus, and the default (new) OmniFocus database. I saw the same behavior with this stripped-down configuration and no sync set up, so I'm confident that there is nothing about my database or sync connection that is causing the problem. My hardware is a 2011 2.2 GHz 15" MBP, 8GB RAM, 7200 RPM HDD.

Any ideas what I might try, or is this what everyone is seeing?

[Ken Case]

Is this when you first log into Lion? I've noticed that everything can be slow when I first log in: Lion presents a picture of what you were doing when you logged out, then slowly substitutes all the fake windows with real windows as it works through resuming all the apps and context that were there before. (You can see this happen in Terminal if you have windows open: the former text dims once the windows actually become live.)

So if you're seeing this when you first log in and resume your entire Lion session, I guess I'm not too surprised by a 15-20 second delay. But if you're seeing this at other times, it doesn't sound normal to me (since you note that subsequent launch times for you are nearly instant).

The next time this happens, could you pull up Activity Monitor, select OmniFocus (it might help to use the Filter in the toolbar), then press the Sample Process button in the toolbar? That will tell us what OmniFocus is doing during that delay: whether it's working on some internal database upkeep, or waiting for some external service, or doing something else altogether.

[Greg Jones]

It is not only when I first log into Lion. The behavior is very consistent-if there has been around an hour or so since I last launched OmniFocus, then I see the delay.

I suppose I could just launch OmniFocus and leave it open, but I tend to only want the apps open that I am working with at the moment. I will capture the activity sample as you suggested and send it in to the ninjas. Thanks Ken.

[Greg Jones]

Here is an update. When I had quit OmniFocus about 30 minutes ago, I had resized the window so that I could see OmniFocus while viewing the activity in Activity Monitor. I just launched Activity Monitor, put OmniFocus as the filter in the search bar, and launched OmniFocus.

As OmniFocus launched, it began the stalled beach ball process. I then selected it in Activity Monitor where it had turned red with the warning 'Application not responding'. I have submitted the ample process-hopefully the report will give some insight as to what is going on.

[whpalmer4]

Just a wild-ass guess, but do you have any printer issues? What about network disks?

[Greg Jones]

I didn't have any printers installed when I ran the test in my first post, although there are two wi-fi printers on my network. The only disk on the network is a Time Capsule, and that too had not been setup for this Mac when I ran the initial test.

[whpalmer4]

Ah, but has this computer ever had printers installed/configured? I'm thinking that OF might be looking for them at launch time and not finding them, and the print subsystem caches that information for a while (so OF launches shortly thereafter are quick, but not so quick after the cache is aged out). Do you have the same issue if you make a new user account and try it there?

[Ken Case]

Originally Posted by Greg Jones

As OmniFocus launched, it began the stalled beach ball process. I then selected it in Activity Monitor where it had turned red with the warning 'Application not responding'. I have submitted the ample process-hopefully the report will give some insight as to what is going on.

It sure does! Thanks for sending that in.

The entire time of the sample is spent in -[NSDocument _hasConflicts], a private AppKit method which presumably checks to see if there are any unresolved version-editing conflicts for your document (in this case, the OmniFocus database which is managed by NSDocument). Here's the relevant part of the call graph:

    +                                 2615 -[NSDocument _handleConflicts]  (in AppKit) + 123  [0x97b8ca73]
    +                                   2615 -[NSDocument _hasConflict]  (in AppKit) + 63  [0x97b8c9ee]
    +                                     2615 +[NSFileVersion(NSTemporaryCompatibility) unresolvedConflictsExistForItemAtURL:]  (in Foundation) + 64  [0x9381557b]
    +                                       2615 LBRevisionHasUnsavedConflictForURL  (in Librarian) + 57  [0x5fba786]
    +                                         2615 _LBFVSendMessageWithReply  (in Librarian) + 645  [0x5fba65e]
    +                                           2615 xpc_connection_send_message_with_reply_sync  (in libxpc.dylib) + 233  [0x9399bbe2]
    +                                             2615 dispatch_semaphore_wait  (in libdispatch.dylib) + 36  [0x974b48fc]
    +                                               2615 _dispatch_semaphore_wait_slow  (in libdispatch.dylib) + 117  [0x974b4800]
    +                                                 2615 semaphore_wait_trap  (in libsystem_kernel.dylib) + 10  [0x988fcc5e]

I'm not sure why this would be taking so long; until now, I didn't realize that that conflict check was happening at all when opening an OmniFocus "document", or that that check involved a separate process. (Looking at the lower bits of that call graph, it's sending a message to another process and spending all its time waiting for that process to reply.)

Making this even more challenging is that we're not seeing this problem ourselves, so we can't reproduce it to try to figure out if there's something we can do to avoid tickling the behavior. But I'll run it past the rest of the team to see if anyone has any ideas.

P.S. — It's possible that whatever process we're calling out to would show up in Activity Monitor as busy during that time; if so, it might be helpful to know what process that is.

[Ken Case]

Apparently we've seen similar pauses when working on our iPad apps in the iPad simulator: they run into that same XPC delay in +[NSFileVersion unresolvedConflictVersionsOfItemAtURL:], just called from UIDocument rather than NSDocument. Not sure if there's anything we can do to work around either issue. (We filed a RADAR some time ago on the simulator behavior.)

[Greg Jones]

Thanks Ken-I appreciate everyone looking into this. I did look at Activity Monitor to see if any other process showed as busy, but I did not notice anything. Also as a FYI, I do not see this behavior with OmniOutliner Pro or OmniPlan in case there is something different in how the apps are coded to use NSDocument. Also, I have never experienced this with OmniFocus on Leopard (on another Mac) or with Snow Leopard on this Mac, so perhaps there is hope that a Lion update will resolve the issue.