OS X 10.10 (Yosemite): Unacceptable levels of responsiveness

Posted by Pierre Igot in: Macintosh
November 27th, 2014 • 10:32 am

In the summer, I bought a new Mac Pro. My previous machine (a 2009 Mac Pro) was getting long in the tooth. It would have lasted a while longer, but then one of my screens broke and I had to replace that, so I figured that, the 2013 Mac Pro having been out for a while, it was as good a time as any to proceed with the upgrade that I had been planning to do eventually.

When I purchased the expensive new Mac Pro (along with a new screen, and Thunderbolt storage), I figured that I was making an investment for the next few years and paying for the guarantee of a high-performance machine that would be able to take full advantage of the upcoming software releases, including OS X 10.10 (Yosemite). I certainly did not expect to have to deal with a sluggish operating system any time soon.

Then along came Yosemite. I didn’t upgrade until the official 10.10.1 version came out. Last Thursday, I downloaded the OS X 10.10.1 package from the App Store and installed it. As system upgrades go, it was relatively painless. I had made sure that all my applications were up to date, and that known issues were properly dealt with. (I use Snapz Pro X for screen captures, but I can live without audio support for a little while, although the slow release of software updates by Ambrosia is getting irritating.)

After installing Yosemite, however, I immediately started noticing significant responsiveness issues. Most notably, I would regularly encounter a situation where clicking on a menu heading in the menu bar would fail to highlight the menu heading and bring down the menu itself right away. It would take a second or two, by which time my muscle memory had already taken me elsewhere, and so I would lose the focus and have to start all over again.

This was just one particular, obvious manifestation of the responsiveness problem. But it certainly wasn’t the only one. There were pervasive issues throughout the user interface and in various applications.

I did what an experienced troubleshooter would do, i.e. I tried to determine whether there were obvious culprits. I stopped using a couple of things that I didn’t absolutely need, such as Flux (which seemed to be making the problem even worse in the evenings). I cleared caches. I deleted preference files. I went through extensions, launch agents and launch daemons. I checked the system logs in the Console. I noticed a number of suspicious-looking error messages in the Console, with no indication of what I could do to stop them.

In particular, I noticed that I would occasionally get this message:

14-11-27 09:50:39,746 sandboxd[283]: ([241]) deleted(241) deny mach-lookup com.apple.desktoppicture

along with the creation of a new log file in /private/var/log/asl/, inside a folder called “AUX” followed by the date. The log files thus created all had similar contents, always starting with:

Process:         deleted [265]
Path:            /System/Library/PrivateFrameworks/CacheDelete.framework/deleted
Load Address:    0x102062000
Identifier:      deleted
Version:         ??? (???)
Code Type:       x86_64 (Native)
Parent Process:  launchd [1]

This was still going on a week later. After some house cleaning, I thought I had eliminated the problem. And then this morning, another similar one started. This time, I still get something from sandboxd, but it involves a different “mach-lookup”:

14-11-29 14:41:10,278 sandboxd[295]: ([378]) softwareupdated(378) deny mach-lookup com.apple.webinspector

Here again, each time the message appears,a new log file is created inside a folder called “AUX” followed by the date, in /private/var/log/asl/. The full logs all have similar contents, always starting with:

Process:         softwareupdated [378]
Path:            /System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated
Load Address:    0x107289000
Identifier:      softwareupdated
Version:         ??? (???)
Code Type:       x86_64 (Native)
Parent Process:  launchd [1]

I have no idea what it means. I was able to reproduce this problem on a clean install of OS X 10.10.1 on a separate partition, although the actual error message in the Console was, again, different in that system, and the number of logs thus created was much smaller. So there’s something going on here. However, I have no idea whether it has anything to do with the responsiveness issue.

Responsiveness issues are hard to describe. But over the past 24 hours, I have been able to identify one obvious symptom, which is 100% reproducible on my 2014 Mac Pro with a clean install of OS X 10.10.1 on a separate partition. Whenever I click on the “Help” menu, in any OS X app, the drawing of the blue highlighting behind the blue heading is so slow that I can actually see it happen in real time.

I have even been able to record the problem with QuickTime Player’s screen recording feature. Here’s the movie that I created:

And here’s a frame of the movie that illustrates the very problem I am describing:


This is a picture of Yosemite caught in flagrante delicto drawing the blue highlighting for the “Help” menu heading as a snail’s pace.

Now, I don’t know about you. But I have spent thousands of dollars on this new Mac Pro, and I certainly didn’t expect to find myself, in late 2014, repeatedly staring at such sluggishness.

Again, I can reproduce this particular problem on a clean install of OS X 10.10.1 on a separate partition. This is not something that is due to some third-party software conflict.

How can Apple’s engineers justify this? Do they really think we won’t notice? Do they really think we won’t care?

Well, I am sorry, but after having paid that kind of money for this machine, I do notice, and I do care.

Granted, this particular behaviour with the “Help” menu heading appears to be unique. I cannot reproduce the same extremely slow (relatively speaking) “filling down” of the blue background with other menu headings. But it’s just one of the most obvious symptoms of a pervasive lack of responsiveness in Yosemite, even on a brand new 2014 Mac Pro with tons of RAM and a large SSD startup disk.

Other menu headings behave somewhat better, but they still don’t feel normal to me. I quite often notice that the menu itself is drawn by OS X before the blue highlighting of the menu heading comes on. And, as I said, sometimes there is even a delay of a second or two before anything happens after I click on the menu heading.

How on earth did we get to this? How on earth can such sluggishness be deemed acceptable on such a powerful machine? I really feel that I have been had.

I might be in a minority that actually notices such things and cares about them. I know that other people are reporting even more egregious responsiveness issues. These are positively awful. My issues are not that bad. But they are still bad enough to be deemed unacceptable after having spent so much money on new hardware.

Yesterday I decided that I had had enough and picked up the phone to call Apple Care. After all, my new Mac Pro is under warranty. I was fortunate enough to get through to a nice fellow named Justin, who immediately grasped that I was an experienced troubleshooter myself and didn’t make me go through the most obvious steps, which I had already done.

He readily agreed that the type of performance issues I was describing was not acceptable for a user of a fully-decked 2014 Mac Pro. And he also fully acknowledged that having to spend hours trying to troubleshoot such issues was a waste of my time and that it was important that we came to some kind of resolution.

We tried a few things, and then we came to the conclusion that I definitely would have to try and reproduce my issues on a clean install of OS X on a separate partition. He asked me to proceed with that and set up an appointment for Apple to call me back Friday morning.

So that is what I did last night. I cursed OS X’s default behaviour, which erases the OS X installer after it’s done installing the software, and proceeded to re-download Yosemite from the App Store, which of course took a couple of hours with my 7 Mbps connection. I created a separate partition on my SSD and installed the software, which was reasonably fast. (Still, I don’t understand why the OS X installer cannot install OS X on another volume in the background while letting the user continue to use his current system on his current startup volume.)

I didn’t spend enough time on that clean partition with nothing installed to try and reproduce all kinds of responsiveness issues. But the slow drawing of the “Help” menu heading highlighting is definitely there, and that in itself is unacceptable.

I fully intend to use this particular example (and refer to this blog post) when Apple (Justin or someone else) calls me back tomorrow morning to find out what happened with my clean install of OS X 10.10.1 on a separate partition.

Will they acknowledge that there is a responsiveness issue with Yosemite? Will they try to argue that it’s “normal” for a .1 release and will be addressed eventually? I guess we’ll see. Justin promised me that he would escalate the issue if we couldn’t resolve it. I’d be really curious to have the point of view of an engineer on this situation.

That said, I want to stress that the problem with the “Help” menu heading is just one of the tips of the iceberg as far as I am concerned. I have chosen to single it out because, in my view, it’s so egregious and outrageous, and also fairly easy to reproduce (at least on my machine).

Since Mavericks was running fine on this Mac Pro (except for some more minor issues), it is really hard to imagine that there is any basis for blaming the hardware for any of this. It is so obviously a problem with Yosemite that I sure hope to be able to convince someone that something is seriously wrong and that something really need to be done about it really soon. Otherwise, I am going to start talking about asking for my money back!

Comments are closed.