Optimize particle effects for Folia#206
Conversation
Thorinwasher
left a comment
Thorinwasher
left a comment
There was a problem hiding this comment.
It's probably alright, but I often get a bad feel when you allow multiple threads to write to the same field. Wouldn't an alternative optimization be to only run the task (which is used on all other non folia alternatives) on loaded chunks, that would probably help well enough.
| private Color particleColor; | ||
| private final Location particleLocation; | ||
| private final UUID id; | ||
| private volatile MyScheduledTask foliaParticleTask; |
There was a problem hiding this comment.
I started digging a bit into why you would use the volatile keyword here when you're also using the syncronized keyword. I don't think it's necessary as modifying something with a synchronized block also force updates the value for other threads (at least from what it seems like when digging some stuff up)
There was a problem hiding this comment.
Hey, sorry for the delay, I kinda forgot about this PR. Anyway, that is right, I guess volatile is redundant here
| if (!config.isEnableCauldronParticles()) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
I don't see why you can't just avoid starting the task if it's disabled in the config.
There was a problem hiding this comment.
Hmm I’ll clean this up so disabled config doesnt start the task instead of having the repeating task poll that setting
Welll, that wouldnt remove the global per-tick scan though. The solution I did is to just avoid that scan altogether and to run it directly in the region scheduler of each cauldron |
|
I've been without proper internet for 6 days now. Will get back to it when internet is fixed. If I forget, just ping me |
2 participants
Hey there!
On Folia, cauldron particles were driven by a global 1-tick task that repeatedly scheduled global tasks for many cauldrons, causing heavy global-thread usage. This change moves particles to per-cauldron Folia region timers. It also switches particle RNG calls to ThreadLocalRandom. Now particle effects stay on the owning region thread and avoid the previous global thread hotspot while preserving behavior.
Here is a Spark report snippet showing the issue:
(Ran using canvas's global-tick profiler)
Tested in production already, and I can confirm BreweryX no longer uses any significant % of the global thread