Performance issues on Mac OS X

Hello,

I've been working for a while with my Uno on an aging 2006 Core 2 Duo MacBook running Lion, and everything's been working fine. Most sketches I've done compiled and uploaded in under 10 seconds.

I now moved the Arduino to my 2009 Quad-Core Mac Pro and even "Blink" takes a minute or two to compile (with or without the Arduino plugged in), which is ridiculous.

I've checked Software Update for Java issues but I'm running the latest of everything.

What could be the problem here?

Thank you.

EDIT: Same slow performance on iMac 20" 2008 running Snow Leopard (same version as Mac Pro, 10.6.8). Is there a known performance gap between Lion & SL when running Java (I'm talking about a 20-30 performance multiple here).

EDIT 2: In case proof was needed, definitely not a CPU issue, as running Arduino on Windows 7 inside a Virtual Machine on Mac Pro Snow Leopard compiles very rapidly indeed. It seems to be an OS X SL issue.

P.S. Note to forum moderators : you actually have to disabled smileys in order to have 10.6.8 appear without sunglasses...

Ischia:
P.S. Note to forum moderators : you actually have to disabled smileys in order to have 10.6.8 appear without sunglasses...

It isn't because of 10.6.8. It is because "8)" causes sunglasses, like you used here:

Ischia:
EDIT: Same slow performance on iMac 20" 2008 running Snow Leopard (same version as Mac Pro, 10.6.8). Is there a known

Ischia:
Hello,

I've been working for a while with my Uno on an aging 2006 Core 2 Duo MacBook running Lion, and everything's been working fine. Most sketches I've done compiled and uploaded in under 10 seconds.

I now moved the Arduino to my 2009 Quad-Core Mac Pro and even "Blink" takes a minute or two to compile (with or without the Arduino plugged in), which is ridiculous.

I've checked Software Update for Java issues but I'm running the latest of everything.

What could be the problem here?

If you are on a Mac, you can "sample" the process(es) you might be interested in during those two minutes. Maybe the Arduino app and avr-gcc (or some other part of the gcc toolchain.)

Hello Ischia,

I've used multiple versions of the Arduino IDE on a Macbook Pro purchased 6/2009 with
2.66 GHz Intel Core 2 Duo Processor
4 GB of RAM
OS X Version 10.7.4 (the latest version) and previous versions of OS X

Both the latest version of the Arduino IDE (Arduino 1.0.1 from 5/2012) and the previous version have worked very well. I also just did a quick sanity test. I uploaded the simple LCD Hello World example sketch to an Arduino Uno R3 board and it took about 3 seconds before the LCD began updating. That sketch is running correctly on a 16x2 LCD as I type this reply.

In addition to what The Clever Monkey suggested, what you may want to try is to run the OS X "Activity Monitor". Forgive me if you know all of this but just in case, and if you're not already familiar, you can run it by doing a Spotlight search (click the magnifying glass from the desktop and type "activity", then click the "Activity Monitor" selection - and the default location for Spotlight is the far upper right of the desktop).

Using Activity Monitor you can see your machine's CPU usage, how much free memory you have, etc. by clicking the related tabs. Where memory is concerned, if your Wired memory + Active memory is close to the total amount of RAM installed on your computer then you are nearly out of Free memory (in OS X, the Inactive memory counts toward Free memory so you can add the Free + Inactive to get the total amount of Free memory).

You've probably done all of this but if you have something running out of control (or even if you don't), try restarting your computer and run Activity Monitor again. If all is well try running only the Arduino App and see how you make out.

Good luck.

I forgot to add that the Mac Pro I'm trying to work on is primarily used as my Digital Audio Workstation, has 16 gb of RAM and has the advantages of being very familiar to me. I'm running Cubase 6.5 + VEP + huge sample libraries) regularly and I'm very sensitive to performance glitches, so I think I would have noticed if a process was hogging the OS...

Anyway, here's what happens when I compile the example "Blink" sketch:

  • The "Arduino" process hovers around 5% with spikes at 12% (this is a Quad-Core Xeon with HT).
  • No other processes are even remotely close to that usage while Arduino's running (the list is sorted by CPU%).
  • Only if I set the Activity Monitor update frequency to very fast, I then see a process called "JavaApplicationStub" appearing at 100% and disappearing almost instantly.
  • The entire compile process takes 50 seconds, more than 20 times slower than on a MacBook which is three years older... See the attached CPU meter history which shows exactly what's going on from process start to finish.

Maybe gcc (or some other dependency) needs to be updated, or changed? I really don't know, I'm stumped here. I don't think it has anything to do with the Xeon or Hyperthreading, because like I wrote previously my 2008 iMac is just as slow. It really looks like a Snow Leopard issue on my end.

I've also attached a process sample for Arduino in case someone can figure anything out of it.

Thanks a lot for your help.

Arduino CPU history.jpg

Sample of Arduino.txt (60.1 KB)

Hi Ischia,

In my humble opinion I think you're on the right track regarding software versions. Below I have a couple of questions and some notes I took while looking through your sample that you provided (this took me far longer than intended so I included them here just as a history of the investigation). My questions for you are:

What version of the Arduino IDE are you running?
I'm running Arduino 1.0.1 (5/21/2012)

What version of Java are you running?
I'm running
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
You can get this from the Terminal command line by typing
java -version

When I was running Snow Leopard I was using Arduino 1.0 (11/30/2011)

If it were me, I would spend time looking at the versions of software running, and not where I just spent way too much (see below).

=== Investigation notes ===

On my computer I captured a sample (a few times) of an Arduino Upload using the blink program to compare with your sample. The three main things I looked through were garbage collection, exception handling, and anything that was doing any locking, blocking, or some kind of wait.

I scrolled through both stack traces comparing the samples side by side and they are quite similar. Things of note were listed in the summary at bottom

Ischia's environment
Total number in stack
JVM_RaiseSignal calls: 95

Sort by top of stack
mach_msg_trap: 65303
semaphore_wait_trap: 2425

avr6130's environment
Total number in stack
JVM_RaiseSignal calls: 0

Sort by top of stack
mach_msg_trap: 15561
semaphore_wait_trap: 784

As you can see your environment is raising signals where mine is not, but maybe more importantly you have many more instances of functions that are waiting/blocking.

JVM_RaiseSignal could be problematic. It is often used to handle errors at runtime and in that case may perform stack unwinding. However it would probably register in CPU time, which as you've shown is not excessive. Still, in my capture(s) no signals are being handled.

With respect to the "waiting/blocking" functions,
mach_msg_trap and semaphore_msg_trap are functions that wait for some result before the application's process can continue with normal execution. This waiting would likely not register under CPU time, but would definitely contribute to delays.

While all that may be interesting (or not), since you are not developing the code the only thing you can do is focus on the compatibility of the installed software (see point above :slight_smile: ).

I really appreciate the time you took to look at that closely. Here are some answers to your questions:

Arduino IDE version: 1.0.1 (latest as of June 10th 2012).

java -version in Terminal gives this:

java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

I didn't understand a lot of the part concerning the process sample, except that a large number of error flags were being raised for some reason... :slight_smile: On my 2008 iMac I tried reinstalling the latest Xcode for Snow Leopard but that didn't solve anything (I'm testing stuff out on the iMac because I can't afford messing too much with my Mac Pro environment).

I also tried creating and logging into a fresh admin account, doesn't help either.

Looks like I'll have to fire up my Windows 7 VM on the Mac Pro in order to program efficiently, which is the most absurd statement ever made unfortunately.

If you have any other ideas to try, I'll be grateful. I am anyway, though, like I said :slight_smile:

Wow - you responded before I made final edits to my post! What I added was formatting around the statement that those blocking functions will definitely cause delays, but not accumulate CPU time. You're environment is performing ~50,000 more of them than mine. Each one will add up. It could only be a matter of milliseconds, or it could add up to never finishing execution. In case you don't know semaphores are used by a process for thread synchronization, like when there is a shared resource (one thread that wants to read a file must wait for another to finish writing to it). As an example, poorly written code could possibly block literally forever on a single semaphore wait, but that is not the case here.

That signal handling (possibly exceptions) could be a clue. Here is something you can try:
Using Spotlight, type "console" and click the top hit (it should be the console application). In the resulting console window on the left hand side, the top heading (at least on my machine) is "System Log Queries". Where ever it is, click "All Messages" under that heading. In the window on the right, scroll down to the bottom of the log file and click on the last line (make sure the latest entries are on the bottom - what you click on should be the latest entry). That will give you a reference of the last line before any more messages were added.

Now in the Arduino IDE under the "Arduino" menu, click "Preferences" and then next to "Show verbose output during:", click both the "Compilation" and "Upload" check boxes. What will show up in the console log will be identical to the output in the Arduino log area but what is nice is it will also have timestamps with HH:MM:SS where the Arduino IDE output does not. This (hopefully) will show you exactly how long each phase in the upload is taking. Do that before changing anything in the next steps so that we have more data from an unhealthy environment.

Some things I forgot to ask is what version of Arduino board are you using? I'm using an Uno R3.
Also, in the Arduino IDE, what selections are checked under the following:
Tools -> Board
Tools -> Serial Port
Tools -> Programmer

Let me know. I'm heading out for a bike ride so I'll be away for a bit.

Tony

Ischia:
I really appreciate the time you took to look at that closely. Here are some answers to your questions:

Arduino IDE version: 1.0.1 (latest as of June 10th 2012).

java -version in Terminal gives this:

java version "1.6.0_31"

Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)




I didn't understand a lot of the part concerning the process sample, except that a large number of error flags were being raised for some reason... :) On my 2008 iMac I tried reinstalling the latest Xcode for Snow Leopard but that didn't solve anything (I'm testing stuff out on the iMac because I can't afford messing too much with my Mac Pro environment).

You don't need dev tools to sample a process. This is done via the Activity Monitor. Find a longer running gcc process you suspect of taking some amount of time, and "sample" it. There should never be an error associated with this action unless something is really wrong.

Admittedly, there could be a large number of gcc processes started and killed at any given time, so there could be a message about a process no longer being there by the time you sample it.

Also, do you have enough disk space to swap all that process space? What are the sizes of the files in /var/vm? How much disk space do you have left on the boot volume where /var/vm resides? df -h from the terminal will be sufficient.

Whoah, lots of questions again... Here goes:

@The Clever Monkey:

df- h

Filesystem           Size   Used  Avail Capacity  Mounted on
/dev/disk0s2        316Gi  240Gi   75Gi    77%    /
devfs               115Ki  115Ki    0Bi   100%    /dev
/dev/disk0s3        280Gi  167Gi  113Gi    60%    /Volumes/BOOTCAMP
map -hosts            0Bi    0Bi    0Bi   100%    /net
map auto_home         0Bi    0Bi    0Bi   100%    /home

In case it's not clear from the above, the OS volume has around 80 gb free on it.

/var/vm

Mac-Pro:vm tz$ cd /var/vm
Mac-Pro:vm tz$ ls -a -l
total 131072
drwxr-xr-x   3 root  wheel       102 Jun 10 09:55 .
drwxr-xr-x  27 root  wheel       918 Apr 11  2011 ..
-rw-------   1 root  wheel  67108864 Jun 10 09:55 swapfile0

The /var/vm question (which I don't understand anyway, I suppose it's related to the swapfile...) might be related to what @avr6130 was asking. When launching Arduino, before trying to compile, the Console says the following:

6/10/12 6:48:58 PM	Arduino[5332]
MDS Error: unable to create user DBs in /var/folders/IG/IGRC3GRoG-C6X1jlkPAEsk+++TI/-Caches-//mds

It says so several times. See the attached text file which is a copy of everything sent to the Console, including the compile process. The two are separated by some text that I added to make this clearer.

As to the other settings asked by @avr6130: the board is an Uno (Rev3), but that doesn't matter imho. It's not even plugged in because after several tests I noticed that the MacBook and the Mac Pro behave identically (great and bad, respectively) whether the board is plugged in or not (i.e. if I now compile "Blink" on the MacBook without even bothering to connect the board, it still compiles almost instantly, while the Mac Pro, even with the board, is very slow).

Anyway, I just plugged it in so I could answer your question: Board = Uno, Serial Port = /dev/tty.usbmodem5d11/, Programmer = AVRISP mkII (I don't even know what that is and I never had to touch it, on any computer). I should add that uploading stuff to the Uno works (eventually) with these settings (i.e. I can get code to run on the unit). Uploading is also a bit slower than on the MacBook but nothing like the time it takes to compile.

I hope this helps you figure this out.

Thanks a lot again.

console.txt (30.1 KB)

OK. I started comparing your log to one that I created. In the mean time, would you please humor me with a silly request? Using Activity Monitor -> System Memory, would you please report back on your memory uses (Free, Wired, Active, Inactive, Used)? With 16GBs, and only Arduino and a couple of system tools running, you should have almost all of that RAM free.

Edit: I forgot to mention Page Ins, Page Outs, Swap Used, and VM size.

Also, with respect to your log error, "MDS Error: unable to create user DBs", it seems to be a common problem, and most of what I read talks about Snow Leopard as having the issue (some people report sluggishness on their Macs which caused them to go digging). MDS is a Spotlight process. Some people solved the problem by rebooting in single user mode (Command Option S) and then later restarting normally. This caused the Spotlight database to be rebuilt. Others removed the directory manually. It was automatically recreated and the problem did go away but in some cases it came back. Below is a several step solution that appears to have worked permanently, at least for this person. This is the solution but check out the whole thread. It's up to you if you want to do it.
https://discussions.apple.com/message/10776481#10776481

I'm going to keep comparing your log to mine.

Since last posting I read all about these /var/folders/ issues, and I ended up trashing the entire folder's contents, which since have been half-rebuilt anyway. It didn't help, of course. I can't boot into safe mode, it's a long story, I'm running a non-EFI GPU here, which only comes to life at the login screen (no boot display). Anyway it's not the issue since, like I mentioned, I'm having the exact same Arduino performance on the 2008 iMac.

The RAM figures you'll see attached are after several hours of surfing, some Java, nothing fancy, with a few login apps running (Sparrow, Dropbox, Evernote, Xmarks, VMWare agent, iStats Menu, nothing really exotic).

RAM.jpg

I was afraid of that but thanks for humoring me. Your log looks very similar to mine, right down to the warnings in the included files. The big difference is that most times it appears to take 2 seconds to compile each package for your compile, where it takes milliseconds to compile mine. As I mentioned before this could be caused by the compile process blocking/waiting (due to the large number of mach_msg_trap and semaphore_wait_trap function calls). That wait time won't show up as CPU cycles, just extra time to complete.

I hate to say this, because you probably have a good reason why you haven't stepped up to Lion on those machines, but that may be your only recourse. You can't say we didn't try.

If you do figure out anything please post to the thread so that I receive an email.

Best of luck.

Tony

Any musician or recording engineer who has a stable and reliable DAW will only upgrade it under torture. The sheer number of tweaks and tests would take a week — you must be unfamiliar with the predictability of high-end audio hardware drivers... So I'll rather work with Arduino on a tiny MacBook screen and not go through that.

The mere idea that such a performance gap could exist between SL and Lion is difficult to grasp. Maybe there are other SL users out there who could provide some feedback? Everything working nicely on your end, or is everyone already on Lion?

I can't say we didn't try, no, on the the contrary, and I thank you very much for everything.

Just chipping in my 2 cents - I'm still running snow leopard, 10.6.8 on an iMac (core 2 duo, 3 years old, 4GB ram) and I have not seen these performance issues. I'm using Arduino 1.0.1 and my compiles happen very quickly. My java reports version 1.6.0_31-b04-415-10M3635.

I don't think the problem is with snow leopard in particular but it could be something related.

For me, setting the board to Uno and compiling (verifying) the blink sketch takes about 5 seconds the first time, and 2 seconds on subsequent verifies.

If you haven't tried yet, how about just repairing permissions? That's chicken-soup for the Mac, and when all else fails it can sometimes fix strange errors.

Thank you Steph for sharing your experience, it helps point out that something is weird with my SL installation and that the OS itself should (and does) perform better.

As to your suggestion, I've gone through Verify Permission a couple of times before even posting the original topic... :slight_smile:

"And now, Ladies and Gentlemen," (opens envelope with ostentatious exhilaration), "The Solution."

(Three trumpets sound in unison)

After Steph's comment, I went and repaired permissions for the tenth time. This time I've looked at all the stuff that was being "repaired" and the list seemed to indicate a stubborn obsession with the Java 1.6 framework.

Reordering Java versions in Preferences, trying to enable 32-bit over 64-bit, none of that helped. At one point I even went "sudo chmod -R 755" on the entire Java directory, but nothing changed.

I've read pretty much everything that Apple had to say on the subject, which wasn't very enlightening. After googling some more I saw people were trying to get Java 1.5 to work on SL in order to keep a few programs they had alive. Apple apparently didn't want this. The version their Software Update imposes on SL users is exactly the same as the one installed on Lion, i.e. 1.6.0_31-b04-415.

Fortunately, there is a step-by-step article dedicated to installing Java 1.5 back in Snow Leopard. I followed it religiously. You end up with two Java installations, as can be seen in the attached screenshot. You don't even have to reorder them.

I've just compiled "Blink" in less than a second. Uploading took another second or two. I hope it's really fixed, it looks like it anyway.

Many thanks for all those who took the time to help.

Screen shot 2012-06-11 at 3.18.50 PM.jpg

Wow glad to hear that it's working, after all that!

One other comment I have, is there's been recent security concerns with java and running an older version might leave some vulnerabilities. Since the most recent version was obviously having issues for you, it could be that it just got corrupted somehow, or maybe even had some preferences messed up. So if you are feeling adventurous, you could try completely uninstalling / deleting both versions of java, and getting rid of the java preferences file (in ~/Library/Preferences) then reinstalling the latest version and see if that works ok.

Cheers!

Thanks, but I had reinstalled the latest Java 1.6 from Apple before going the 1.5 route (forgot to mention that). It didn't help, that's why I went with 1.5.