You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After installing ghub, OBS started lagging for 5 to 10 seconds after every single action that I perform inside of obs (things as simple as clicking on a different scene!). I have a 5950x with 128 gigs of ram, so this should really not be happening. I was able to reduce the problem down to this plugin (which, notably, seems to secretly install itself and there is no option in ghub to turn it off). Deleting the plugin fixes the issue so that there is absolutely no hang after any action, however ghub keeps silently reinstalling the plugin every time i delete it.
The performance issue seems to be caused by logi::applets::obs_plugin::helper_populate_collections. This is executed after most actions in OBS, and inside of the function it is redundantly accessing a nested std::map for every single source in every scene. Also, for each of those redundant lookups, multiple new and redundant std::strings are created.
There are a few easy ways to fix this without changing the structure of the plugin too much at a high level:
Don't perform redundant lookups into the maps. Each operator[] call has to do a lookup through the entire map. If you need to index, it's best to do it exactly once per element and hold onto a reference to that element.
Use a container other than std::map. If using a different standard container, std::unordered_map will be the easiest drop-in replacement and has better complexity for the operations being used.
Don't create redundant std::string objects. Modern c++ standards allow for heterogeneous lookup into associative containers. This means that you do not have to create even a single std::string just indexing into an associative container.
I cannot be the only person to have been impacted by this, but I'm sure those who are impacted just assume that it is OBS itself that is the culprit and have not looked into it more deeply. The problem also gets more pronounced as the amount of sources increases. I have a [relatively] large number of sources in OBS, but nothing too extreme and I am sure that there are people with more. Anyone who has a moderate amount of sources and has ghub installed will experience this issue.
The text was updated successfully, but these errors were encountered:
After installing ghub, OBS started lagging for 5 to 10 seconds after every single action that I perform inside of obs (things as simple as clicking on a different scene!). I have a 5950x with 128 gigs of ram, so this should really not be happening. I was able to reduce the problem down to this plugin (which, notably, seems to secretly install itself and there is no option in ghub to turn it off). Deleting the plugin fixes the issue so that there is absolutely no hang after any action, however ghub keeps silently reinstalling the plugin every time i delete it.
The performance issue seems to be caused by
logi::applets::obs_plugin::helper_populate_collections
. This is executed after most actions in OBS, and inside of the function it is redundantly accessing a nestedstd::map
for every single source in every scene. Also, for each of those redundant lookups, multiple new and redundantstd::strings
are created.There are a few easy ways to fix this without changing the structure of the plugin too much at a high level:
Don't perform redundant lookups into the maps. Each
operator[]
call has to do a lookup through the entire map. If you need to index, it's best to do it exactly once per element and hold onto a reference to that element.Use a container other than
std::map
. If using a different standard container,std::unordered_map
will be the easiest drop-in replacement and has better complexity for the operations being used.Don't create redundant
std::string
objects. Modern c++ standards allow for heterogeneous lookup into associative containers. This means that you do not have to create even a singlestd::string
just indexing into an associative container.I cannot be the only person to have been impacted by this, but I'm sure those who are impacted just assume that it is OBS itself that is the culprit and have not looked into it more deeply. The problem also gets more pronounced as the amount of sources increases. I have a [relatively] large number of sources in OBS, but nothing too extreme and I am sure that there are people with more. Anyone who has a moderate amount of sources and has ghub installed will experience this issue.
The text was updated successfully, but these errors were encountered: