Does changing colorMode() from RGB to HSB affect performance in any way? In other words, does it require more processing power to convert everything back to RGB if you switch to using HSB?
I’ve switched to HSB because I find it easier to programmatically change colours, but I’m worried it may have ever so slightly slowed down the speed of my sketch. It could certainly be a number of other things, but I just wanted to rule out that switching to HSB might have had a negative impact on the performance of my sketch.
Thanks in advance!
EDIT:
Here is a performance comparison between RGB and HSB color modes. Please let me know if you notice one performing worse than the other!
Since the image is stored in RGB format then the HSB values must be converted to RGB first so I would think that performance will be slightly reduced, but as Kevin suggested try it.
Did you start with using RGB and then switch to HSB? If not how would you notice the difference?
Is it me, or does it appear as though the RGB version performs ever so slightly better than the HSB version?
Since the image is stored in RGB format then the HSB values must be converted to RGB first so I would think that performance will be slightly reduced, but as Kevin suggested try it.
Thanks, I was curious if this was the case.
And yes, I switched to HSB and felt like I noticed a difference, but wasn’t sure if it was due to my laptop using up resources elsewhere at the time or something.
The performance is still OK, but I was sad to feel that I lost the silky-smooth animation that I had with RGB because I switched to a color mode that I find easier to work with.
Out of curiosity, do you notice any difference between the RGB and HSB versions above?
Too really benchmark it, I would not perform the test like this. You can’t just see with your eyes because the difference won’t be that big plus I think Processing cap the framerate at 60 fps so it won’t be enough anyway to see the effect.
Instead, just use a for loop that draw a rectangle with a color over and over until you’ve reach 1 million rectangle (for example). Get the time before the for loop, the time after the for loop, do the difference and compare both of the color mode.
It looks like you’re calculating the color once when creating the particles, so I think it should not have any effect, or? (except for a possible tiny initial delay)
It would be different if you would be calculating a new color for each particle on every frame. In that case, if it was harder to calculate an HSB color than an RGB color, you might see a difference.
But @jb4x is right. To really test it, maybe don’t even draw anything? Then you can measure how much time it takes to calculate billions of RGB or HSB colors, without any other elements interfering the measurement.
Thanks everyone, it seems as though the difference is negligible at worst.
Moving on from this, where would you say is the best place to start for trying to analyze/pinpoint which parts of my code are affecting the performance of my sketch the most?
You can use the millis() function, and put it in specific places in your code to be able to get the time some parts of your code are taken.
For small project it can be done the dirty way but for bigger project you might want to build a custom class so you can easily tag time that you measure and then display the result by tag in the shape of a table.
There is probably some library that already exists.
Every time we invoke functions such as color(), background(), fill(), stroke(), a new p5.Color is instantiated, unless we pass to them an already existing p5.Color instance as their argument.
Dunno whether changing colorMode() can affect the performance of instantiating a p5.Color.
But if we cache p5.Color instances created by color() as our custom palette, and reuse them for the other color changing functions, we’ll avert the whole color conversion stuff, w/ added bonus of less work for JS’ GC:
