The Robservatory

Robservations on everything…

 

Yosemite’s constant clattering clutters Console

For those who aren’t familiar, Console (found in Applications > Utilities) is an application that shows you what’s happening beneath the lovely skin of OS X. Open the application, and you’ll see a combination of status and error messages from any number of sources.

If you’ve never looked at Console before, you might be surprised by just how much stuff gets written there. But with the release of Yosemite, things have really taken a turn for the worse—the amount of stuff written to Console is greater than I recall for prior OS X releases.

As a test, I set up a new Yosemite virtual machine, installed ScreenFlow (and nothing else), then launched and interacted with a number of Apple’s apps for two minutes while recording the screen. The results are quite sobering; here’s what two minutes of Console logging looks like, reduced to a 10-second movie:

As you can see, there are a lot of Console entries in just two minutes.

And what did I do during those two minutes? Here’s a full list of the tasks that generated that output:

  • Loaded two web pages in Safari.
  • Launched TextEdit, created and saved two documents.
  • Launched Calculator and did a couple of calculations.
  • Launched Calendar and added an event.
  • Launched Chess and made a move.
  • Opened two Finder windows and duplicated two files from one folder to another.
  • Launched Dictionary and looked up a word.

And that was all. Just those simple tasks added literally screens of data to the Console log. Now consider a real-world system. With more than just Apple’s stock apps. With more than just simple little tasks. As you can imagine, a ton of data winds up getting written to Console.

Is this a problem? It doesn’t seem to cause any performance problems, though I can’t help but think that there has to be some amount of impact from such voluminous logging.

Does it matter?

If there’s no measurable performance impact, does it matter? In my opinion, yes, it matters. Why does it matter? It matters because of “the boy who cried wolf” story: with so much junky output in Console, it’s really hard to spot the real signs of trouble.

Console has, for me, always been the place to go when an app is misbehaving. You may not completely solve the problem with a trip to Console, but you’d often find useful hints as to the problem’s cause. And you could leave Console open, switch back to the app, and watch for any messages as you tried things in the troublesome app.

But now, with the volume of data written to Console, any sort of real-time troubleshooting is almost impossible—the text just scrolls past too quickly. Instead, I use the search box to search for something, and then look through that output for any relevant messages. This works, but I miss being able to watch as actions were occurring.

How could it be fixed?

So what’s the fix? In an ideal world, apps would only spew to console if a debugging switch were set within the app.

That’s how we try to do it with our Many Tricks apps—if you see output in Console, it’s probably from a program that interacted with us, as opposed to something we generated.

We have switches in each app to enable debug logging, as seen above right. (Generally, hold Control and Option to see the logging option in place of Preferences in each app’s menu.) If the switch is off, we try not to write anything to Console.

But there are a lot of apps out there, obviously, and updating them all with similar features seems nearly impossible. Someone on Twitter, I believe, suggested a great solution: a switch in Console that suppresses “status” messages, leaving only the critical stuff to filter through. That way, no apps need to be updated, and users can control what messages they see.

Sadly, I don’t think we’ll see this, either, but I think something’s got to change; there’s no way the amount of cruft being written to Console is necessary on a regular basis.

3 Comments

Add a Comment
  1. I think you’re basically describing the difference between stdout and stderr. Critical messages should go to stderr, and clattering should go to stdout. Then, if you wanted to see what’s going wrong on your system, you could simply monitor stderr. All we would need to make that happen is two changes:

    1) Make it more straightforward to discern between those channels in Console. Console does have some kind of differentiation (all messages vs. diganostics and usage), but do users understand the difference?

    2) Introduce a stdout equivalent for NSLog(). That’s the function most developers use to log stuff, and it always writes to stderr. That’s conceptually wrong, but a lot of developers (including me, to be honest — at least up to now) don’t seem to think the differentiation is important enough to spend time on creating their own stdout logging functions. Apple also isn’t exactly helping, as illustrated by this quote from TN2347:

    “Many of the system frameworks use NSLog for logging exceptions and errors, but there is no requirement to restrict its usage to those purposes. It is also perfectly acceptable to use NSLog for outputting variable values, parameters, function results, stack traces, and other information so you can see what is happening in your code at runtime.”

    Granted, it’s almost trivial to use printf() instead of NSLog() where appropriate, but even small things like the inconvenience of having to convert NSString objects to C strings can make a difference. Developers are lazy people. ;)

  2. Agreed. All the information is now overwhelming — and mostly useless — to the average user. I used to check Console every now and again to make sure unexpected things weren’t happening and to keep my system fine tuned. Very difficult to do so now. I wish Apple would form an internal group whose sole purpose would be to make OS X the most robust, efficient and bug-free operating system on the planet… with average uptime of weeks or months the norm again. :)

Leave a Reply

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme