Hi there. I’ve been working with p5.js for about 6 months now, and have had an ongoing performance issue even for simple sketches. I’ve been testing it on and off to see how to get to the bottom of it. I have a test sketch that simply paints a 500x500 canvas once per frame, and at 60 fps in chrome or firefox I’m seeing 130-140% cpu usage with pixelDensity(1) set. I’ve been working around the problem with more restrictive frame rates and limiting my sketches, but I’m hoping there may be some real solution.
Computer: late 2013 macbook pro retina, El Capitan 10.11.6, 2.4 Ghz intel i5, 4gb ram
Of course I don’t expect great performance out of this computer, but this is a bit silly.
Hi @matthewjohnjamieson, can you let us know which version of p5.js you’re using? (this should be in a comment at the top of your p5.js or p5.min.js file)
If you’re not doing this already, you might get a performance boost by using p5.min.js which will turn off some of the parameter validation for the friendly error system.
If that’s not applicable, can you run the performance profiling tools in Chrome or Firefox and let us know where the slowdown seems to be? (here’s a nice tutorial on the Chrome tools in case you need it—please disregard otherwise)
Okay so I’m using min, p5.js v0.6.0 January 19, 2018. I get steady usage of 90+% with the following sketch:
function setup(){
createCanvas(500, 500);
frameRate(60);
pixelDensity(1);
}
function draw(){
background(127);
}
Which I’m sure you’ll agree probably shouldn’t be so taxing
I ran the Chrome profiler for the sketch above. It says the sketch is spending the majority of it’s time painting—to which I say sure, I mean, what else would it be doing? So far I haven’t been able to find anything more insightful. It seemingly takes 0.5ms to repaint that background every frame.
Thanks for following up! Hmm, was “painting” the most detail you could get? In the Call Tree tab of Chrome’s Performance Profiler, I can usually dig into Animation Frame Fired to see specific p5 functions that might be taking up the most time.
This is a typical Animation Frame Fired from the profile I ran. requestAnimationFrame seems like it’s the bulkiest part? Some of these requestAnimationFrame’s are calling d.color instead of fillRect. The percentages are similar though. I’ll keep trying to get more detail and see if I can find any red flags.
If we don’t pass an instance of class p5.Color argument to the following p5 methods background(), fill() and stroke(), they’ll have to instantiate a temporary 1 by themselves.
Thanks for looking into this further! At a glance this looked like what I’d expect, but running the same code on my machine (a late 2015 MBP w/ macOS Sierra) yields much lower overhead for requestAnimationFrame. I wonder if you tried a simple canvas (without p5) with your own update loop provided to requestAnimationFrame, would you get similar results? How do the examples on this page work for you? https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations
Thanks for helping me out with this! Running the solar system and clock examples gives me ~55-60% CPU usage. Less than the p5 sketch, but still seems like a lot. Could my OS version be a factor? Using El Cap makes me 2 generations behind at this point.
I’m afraid it could be, but I’d still hope that it wouldn’t be that bad. I don’t know enough about canvas implementations at the OS-level to really have an informed opinion. I wish I had something helpful to suggest as a next step—I’ll keep thinking about this!
I think the only way to eliminate the possibility is for me to upgrade the OS and see what happens. If that doesn’t fix it then at least now we know that’s not the issue.
Well okay, looks like good news so far. The upgrade to High Sierra made all the difference. The empty sketch example now runs with trivial overhead. I made a little “move the particles around randomly” sketch, and I’m getting acceptable performance even with several thousand particles. Thanks again for all your help!
