Perfrmance issues in rendering loop


#1

Hi all,

I’m currently working on a plugin and I have some performance issues that are bothering me.

I was debugging my app and adding a breakpoint in a part of the delete function when I realized that the main loop of rendering (even if there was no interactions with user, peripherals or anything) was calling the delete function.
In fact it appends it several different cases :

  • when creating String (while searching a colour in ComponentHelpers::getColourPropertyId for instance)
  • when calling save and restore graphic constext (the stack used to save the context use refcounted dynamic alloc)

I don’t think it’s the main issue of performance of my app.
BUT I’m still worried about such frequent calls to heap alloc in the rendering loop.

Is it new or not ?
Do you think it can be bad for performance or not ?
Is there any “juce setting” that can change those dyn alloc to preallocated alloc ?

Thanks


#2

Don’t be.

If you’re at all interested in performance, you need to be using a profiler to find the real hot-spots in your app. Otherwise you’ll just waste your time chasing after irrelevant stuff like this.


#3

Hi,

thanks for the quick answer.
As I said it’s not that I think this is really relevant for my all app.
It’s also really true that it is not so consuming (especially because the blocks reserved are very small).

I just wonder why we need to use dyn alloc and not preallocated elements (such as a pool), and if could be more efficient.


#4

Well, it’s a question of economics.

It’d take me at least a few hours, or perhaps a whole day to write some kind of pool allocator for this. How much improvement do you think it’d make to the rendering performance? My guess would be that it might improve it by somewhere between 0% and 2%. (In fact, using pools may even turn out to be slower, these things aren’t easily predictable, and c++ allocators are already extremely fast). And no matter how much it improves it, you have to balance that against extra complexity + potential bugs in the codebase.

Remember the 3 rules of optimisation:
http://c2.com/cgi/wiki?RulesOfOptimization