Though if it does that in 1.5.1, that bug has been around for a while then (unless it has more to do with Java that Processing?). A pretty substantial bug I would think.

I did find some older forum threads where people said the screen size made a big difference (someone reporting high CPU with a 1000 x 1000 screen), but still, i'd think an empty sketch with a screen of almost any size should be near 0% CPU.

Thanks for the info, though my app is a constant animation (2D geometric shapes and sound driven by a realtime data stream the app is pulling from the network), so the noLoop() and/or redraw() options won't really work for it. 

In the full app, which uses the OSC, ControlP5, and Beads (for audio) libraries, I've reduced the frame rate to 20 FPS, but it only makes a marginal difference. I guess my bigger question/concern is: most of the software I use draws/updates at a faster rate with far more complex interactions and graphics than my little 1000x625px application, and doesn't use nearly as much CPU. This is an essentially empty sketch using nearly 40 - 50% CPU. Is it an issue with Processing on OS X? Is it a Java issue? Is it experienced by all other Mac users? and is there a workaround and/or fix in the works? (I realize I may not get answers to most/any of these questions   ). Thanks!

That's a nice idea, though it doesn't seem to work for me. I tried removing the Java subfolder in both 1.5.1 and 2.0b6 and the application just hangs when launching. I also tried removing Processing preference files from Library folder, and the Java application stub that sits in the MacOS subfolder (by subfolder, I assume you're referring to inside the Processing OS X application bundle?).

When I set the preferences in Processing, I've checked 'run applications in 64bit mode' - is that not using Java in 64 bit capabilities? Anyway, I do wonder if it is possible to run another Java version with Processing.