Cache current hotkey settings for each bar

[nebel]

Hello.

This change makes it so that each bar caches the hotkey settings of all its children, eliminating the need to delve the tree of button nodes on every update. Read on for my rationale.

Rationale

For small and temporarily visible bars, checking the Hotkey setting for each button does not take a long time. However, as you may know, there are some quite large and powerful QoLBar presets community members have made, which comprise of thousands of button nodes for e.g. many different teleport locations, including decorative spacers and so on. Normally this carries no penalty as QoLBar will only examine and render the currently expanded nodes. However, hotkey settings are different in that they are re-exaimined on each FrameUpdate to build to global button hotkey list.

In my case I was using one preset with around 1200 nodes in the full tree, and whose bar was permanently visible, and I noticed the FrameUpdate time was more higher than I expected (around 0.0380ms).

Changes

I tried to implement a caching system for hotkey settings. After this change, each bar caches the hotkey settings of its children, so that each frame all we need to do is pull the cache from each visible hotbar rather than having to visit each child. The cache is invalidated only when the top level configuration is changed. This also let me re-arrange a condition so that we pay less in terms of runtime cost for bars which have no hotkeyed children (by eliminating their visibility check when checking hotkeys).

As a result of this, my FrameUpdate time with the 1200 node bar visible is reduced from 0.0380ms to 0.0180ms with a hotkey set in the bar, or 0.0120ms with no hotkeys. For small bars there is no significant performance change (no noticeable slowdown either before or after this change).

Notes

While diagnosing this issue I eliminated the recursive nature of the tree delving and replaced it with a stack-based one in CacheBarHotkeys. I claim no performance benefit to this, but did it just because it's easier to collect the statistics for the PluginLog.LogInformation call there. If you prefer the recursive style I can revert this part and remove the logging.

Thanks for taking your time to read this, and please let me know if you have any concerns or questions.