You will have a hard time tracking down performance issues that come from malloc and friends using a profiler, since it has almost no effect on general throughput / average performance (what a profiler usually measures), but a non-deterministic worst-case behaviour, which can result in clicks even if it runs fine on your system.
But here we go:
- String creation: Big Nope
- ValueTree operations on nonexistent data: Big Nope
- Creation / Destruction of
DynamicObjectsand setting nonexistent properties: Nope - ValueTree operations on existent data: OK as long as you are aware of possible multithreading issues and you are certain that there are no UndoManager and listeners attached (because they would get called synchronously). But better use a
CachedValue<>for accessing ValueTree data from the audio thread. - Undoable operation: Big Nope
- Anything that resizes a HeapBlock: Big Nope
- AsyncUpdater calls: Small Nope (allocates a post message, which is usually very small but nonetheless). The usually suggested solution is to use a Timer with a flag, however if you have a lot of objects that might trigger an update (> 500), the Timer thread will get very busy.
-
new/delete,malloc,free: Huge Nopes -
alloca: this allocates on the stack so it’s OK. I use this once in a while for scratch buffers where I know the size doesn’t exceed 500-1000 float numbers. - MessageManagerLock: Nope Level 9000
- File I/O: Big Nope
- UI operations (any method of the
Componentclass: Big Nope
to be continued…