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

Troubleshoot performance issues, improve monitoring #34

Open
Cervator opened this issue Sep 29, 2018 · 1 comment
Open

Troubleshoot performance issues, improve monitoring #34

Cervator opened this issue Sep 29, 2018 · 1 comment

Comments

@Cervator
Copy link
Member

Starting recently I've noticed an occasional massive performance drop with DC active, both via MedievalCities and TutorialDynamicCities. Unsure if it came in during GSOC 2018 with some related ST changes or just has been hiding for a while.

It is hard to troubleshoot as I'm not sure yet how to reliably trigger it. Sometimes it'll happen before I even find the first village, other times I'll find one village and everything will be fine, then go off hunting another and suddenly the game will slow to a crawl. I fly around with ghost + hspeed

I suspect it might have something to do with scanning the world for suitable settlement sites, but I have no evidence for that. It just seems to trigger based on a number of chunks generated or from characteristics of specific chunks having generated.

To better troubleshoot, even if not resolving the issue, the goal here is to review likely spots for performance problem possibilities and better log/monitor to make finding them easier. When this slowdown occurs there is no unique monitoring category that spikes, when there really should be.

For an example see StateInGame which wraps several monitoring activities around various possible points that might take a while or become complicated in the future. Find similar spots in DC and add a unique new activity.

Example snippet:

        PerformanceMonitor.startActivity("Rendering NUI");
        nuiManager.render();
        PerformanceMonitor.endActivity();

Example target: The update method in SettlementEntityManager, specifically the two for loops. It may also make sense to move the first if block to within the throttling counter:

        if (counter != 0) {
            return;
        }
...
        counter = 250;

(The stuff represented here by ... is what I think we should try wrapping a monitor activity around)

I'm not sure if the stuff in the preceding if block really needs to happen before that counter check. Moving it past it would save that block from running 249 times out of 250 ticks.

@Cervator
Copy link
Member Author

It may be worth reviewing #31 in light of these issues, and see if the new API would be cleaner and perhaps more performant, then wrap monitors around the new stuff instead.

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

1 participant