High CPU usage & Fast Fans when using high frequency event sources

Steps causing the bug to occur

Some compositions using high frequency event sources returns high CPU usage and fast fans spinning on my i5 2,5 4go ram.

How did the result differ from what you expected?


Other notes

  • Vuo version: 1.1.0
  • macOS version: OS X 10.10

Regarding “scrolling the editor is laggy”, is it smooth for small compositions, and only laggy for large compositions? Or if not, when do you notice it the most?

Regarding “receive composition frame turns the fans on”, are you saying that every composition is using a lot of CPU time (I’d be surprised since your computer is faster than mine, and Vuo’s example compositions rarely use much CPU on my system), or does it depend on what nodes are in the composition? Maybe there is a specific node that we could optimize?

We’re constantly working on live-coding performance improvements; you should see a difference in the upcoming Vuo 1.1.0 release.


I made some screenshots using your “show mouse position” sample …

One screenshot with OSX’s activity monitor app and one with the istats app.

Edit: My mac is running 2,3 Ghz instead of 2,5

The fans start after let’s say 1 minute of live coding when using the “requested frame” output as an input for the composition it’s time …


your “show mouse position” sample

Thanks for mentioning that example. It’s odd that it’s using over 100% on your system. (Curious, what is your GPU model?)

That particular composition isn’t designed as efficiently as it could be — instead of querying Check Mouse Status every frame, it could use Receive Mouse Moves which only fires an event when the mouse actually moves. We’ll get that fixed.

On my system, it uses about 35% CPU. I was surprised to see so much CPU taken just from rendering the one layer every display refresh, but it looks like that’s the base cost, and adding more layers to render is not so expensive (adding a couple additional Make Text Layer nodes, CPU only went up a few percent per layer).

In general, we’ve put a lot of effort so far into making Vuo compositions execute as fast as possible, and haven’t focused much on energy efficiency / avoiding doing work unless absolutely necessary. Improving energy efficiency is on our radar (especially when we start working on support for mobile devices).

Not all compositions using “requested frame” as value use that much CPU with fans on.

Other examples are f.e.

  • The “align layers to window” sample composition (see screen capture)

  • The Draw Curve sample composition I slightly modified (see attached)

DrawCurve.vuo (2.79 KB)

Thanks for clarifying. I ran some performance profiles on those 3 compositions, and filed a few internal bug reports toward improving CPU efficiency for them. Tentatively planning to dig into that just after the Vuo 1.1 release.

Perhaps change this discussion name to something like “High livecoding CPU usage when using the requested frame output” as that’s what it is finally about it :)

Updated title and converted to bug report.

Hey …

I’ve been using Vuo on another computer this Week and I had so much fun using it without the fans on that I thought I should document this bug a little more.

So when my MBP 2011 uses frequently updating nodes it gets a high CPU usage and the fans turn on for the whole time of use.

  • So this is not a specific bug to the “Show mouse position” example composition.

  • usually when any of those high frequency events/nodes are used this happens. Those nodes/events for example are:

     - Requested frame from Render X to window (to a curve time input for example) .
     - Capture Image of Screen.
     - Play Audio File.
     - Receive Live Video (Connected to the iSight)
  • However it does not happen when no “Render X to Window” node is used. So if no Window is piped-up, like the “Play Audio File and Loop” example (stays at 20% CPU).

Happens on my 10.9 session just like on my 10.10 :(

I don’t know if it’s my computer only. No similar bug reports from other users ? Maybe I should clean the fans or replace the cooling hardware part ? Not sure …

I’ve attached several screenshots and a composition (with Karl Henkel’s Date and Time and Satoshi’s append zeros Nodes), other screenshots are from the the “Show Live Audio Trail” sample composition. Inlcuded also are screenshots from the idle computer monitoring and screenshots from Vuo Loader measurements as well as exported apps.
I get 70% CPU and 4100 Fans RPM here but sometimes it goes until 90-100 CPU %

PS : The MBP 13" 2011 only has one fan, so the other is not broken ;)

5 - ShowLiveAudioTrail - Exported App.jpg

Vuo CPU.zip (3.55 MB)

5 - ShowLiveAudioTrail - Exported App.jpg

323 % for the “Add Noise To Clay” sample composition :(

BTW this is the graphic card :

Intel HD Graphics 3000 :
Jeu de composants : Intel HD Graphics 3000
Type : Processeur graphique (GPU)
Bus : Intégré
VRAM (totale) : 384 Mo
VRAM (dynamique, max.) : 10
Fournisseur : Intel (0x8086)
Identifiant du périphérique : 0x0126
Identifiant de révision : 0x0009


Anyway … I noticed the fans on my computer go crazy quite often, not only in Vuo. For example sometimes even when I browse pages.

So it has some Apps Like Safari, Vuo, Numbers it doesn’t like.

I don’t know if it is because of High CPU usage, or because of heat CPU. I don’t know if the heat sink/cooler could be broken.

I don’t know.

Just to say even if I get that 300% CPU sometimes in Vuo, my Mac surely has a problem itself !

I don’t know if it is because of High CPU usage, or because of heat CPU.

@Bodysoulspirit, have you tried MenuMeters? It displays CPU usage in your menu bar.


I did not know MenuMeters. Thanks. I had Fan Control & Another CPU stat App.

Here are screenshots of the idle computer and when running Add noise to clay.

But as said, my computer may have itself a problem, and Add noise to clay is not the issue itself I think as many compositions do use high CPU.

I will try to investigate more and isolate some stuff to document the bug here.

Thanks anyway


@bodysoulspirit, could you make a time sample for us?

  • Run AddNoiseToClay
  • In Activity Monitor, select the AddNoiseToClay process, then select View > Sample Process
  • Save the result and attach it here

That may help us figure out what’s going on.

In that composition, Vuo is applying GPU-based mesh filters. Unfortunately the Intel HD Graphics 3000 GPU isn’t very powerful, so it may be resorting to using the CPU instead of the GPU, which really slows things down. In Vuo 1.2, we’ve already made a bunch of CPU and GPU performance improvements, so that may help with some compositions. But for graphics work we recommend using a system that has a discrete GPU (most recent Macs include a discrete NVIDIA GPU).


Here it is. Hope I did the right thing. It’s done in OSX 10.9 please tell me if you’d like 10.10 sample too.

Holy **** I must buy a new Mac ;) But I’m the only guy who reported this high CPU + fan thing here around ?

AddNoiseToClay.zip (48.2 KB)

Thanks for the time sample. I skimmed through it, and, yes, it appears that the mesh filters that are supposed to be running on the GPU are falling back to use the CPU instead (which will be much slower and, of course, more CPU-intensive).

We don’t have an Intel HD 3000 system to test with. We do have a few Intel HD 4000 systems, and I just confirmed that AddNoiseToClay is not falling back to CPU on that system configuration.

I’m not aware of a way to figure out why it’s falling back to CPU on Intel HD 3000 or what we can do to stop it. The only Apple documentation I’ve found is QA1502, which just says it switches to CPU “when the hardware resources are not sufficient for a given operation”.


Strange thing. Ok. I this Macbook Pro 2011 is garbage ;)

Sad cause I can’t afford a new one now and that CPU/Fans stuff is weird to work with (because of my brushed hairstyle for example ;))

But as said, perhaps the computer itself has got a problem !

I’ll see ! And I’ll see how the next versions of Vuo will run. Sometimes, I believe that computers act funny. You change a tiny thing and it behaves a lot more different, sometimes even without purpose ;)

Thanks for the time token anyway.