Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DGS on idle uses a lot of processing power #109

Open
PlatinMTA opened this issue Jan 14, 2022 · 4 comments
Open

DGS on idle uses a lot of processing power #109

PlatinMTA opened this issue Jan 14, 2022 · 4 comments

Comments

@PlatinMTA
Copy link

DGS while idle runs dgsCoreRender every frame. This should be unnecesary, since no DGS elements are on screen or even loaded.

You can check this by opening a clean server, starting DGS and IPB and search Lua timing (option d).

image

This should not be the case. Unless there is a DGS element created or something like debugdgs enabled, there should be no onClientRender or onClientPreRender functions running. They should be added after a DGS element has been created, or even better, when a DGS element is being rendered. This will make DGS perform MUCH better while is not loaded.

On high FPS it can lead for up to 1.5% CPU usage (AMD Ryzen 5 2600 on Windows 10), while on low FPS it gets like 0.4-0.5% CPU usage.

@thisdp
Copy link
Owner

thisdp commented Jan 14, 2022

Note that: @client.lua:137 is the "onClientRender". the real usage should be 1.45% - 0.51% = 0.94%
Because DGS has some basic running requirement. DGS' structure determines this, and fortunately, this can enhance the performance when you have a lot of DGS elements.
In the main renderer, we can make some optimization. But adding extra code to detect the cursor will be much more costly (Or maybe there will be other method to optimize this).
Thanks for your advice. We are on the way to improvement !

@PlatinMTA
Copy link
Author

Note that: @client.lua:137 is the "onClientRender". the real usage should be 1.45% - 0.51% = 0.94% Because DGS has some basic running requirement. DGS' structure determines this, and fortunately, this can enhance the performance when you have a lot of DGS elements. In the main renderer, we can make some optimization. But adding extra code to detect the cursor will be much more costly (Or maybe there will be other method to optimize this). Thanks for your advice. We are on the way to improvement !

I did make a "hack" for an older version of DGS. I started onClientRender on dgsCoreRender after the creation of any DGS element. And every 5000 tick~~ i check on the dgsCoreRender function if there are still DGS elements created, if there are not then the event is removed. The same with onClientCursorMove. I should made it so that it removes the event when there is no element rendering tho, but it's an improvment and I didn't see any side-problems (the event also adds itself when using debugdgs).

I don't know if it's feaseable to do that in a non-hacky way. Didn't bother to think too much about it.

@thisdp
Copy link
Owner

thisdp commented Oct 16, 2022

Optimized onClientPreRender in 3.518.
Need further optimization.

@Fernando-A-Rocha
Copy link

dgs uses a lot of processing power on my server. On idle it's around 1% too, and when used in some UI it can become pretty high

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants