Performance overhead of Global variables vs. Const Var

[Casey Kolb]

Just out of curiosity, does anyone know if there's a big difference in performance between accessing Globals.someComponent and const var someComponent? I'm running a few benchmark tests but it's a bit hard to tell. It seems like const var might be slightly faster.

[Christoph Hart]

Globals are about as fast as normal vars but there are some optimizations possible with const vars that increase the performance (eg. API calls on a const object are resolved at compile time)

[d.healey]

Globals. someComponent sounds like debugging heaven :)

[Christoph Hart]

Ah yes, I oversaw that. Nonononono ;)

[Casey Kolb]

Uh oh, have I made a grave error? haha. A lot of my components are stored in Global variables. Poor design choice I know. Probably need to do some major refactoring.

[Christoph Hart]

The problem with storing UI elements in global variables is that you transfer the ownership of UI elements out of the ScriptProcessor where they have been defined, which might result in their lifetime exceeding their parent processor and this might cause crashes (most likely when you close a plugin).

Why do you store them in Globals?

[Casey Kolb]

@Christoph-Hart I was originally approaching the Globals container like a React state. This was way back when I started this project and I just continued with that paradigm without realizing how HISE restores its state. However, I totally see the danger here. I'll need to refactor it all.

On another note, I'm trying to understand the optimization of the const var. If I store a bunch of UI elements in one const var thisNamespaceUI = {} for clarity, do I get the same compile optimizations as if I were just storing them in individual constant variables? For example, you'd have thisNamespaceUI.panelOne.buttonOne thisNamespaceUI.panelOne.buttonTwo etc.