search

EnigmaticaModpacks / Enigmatica6

The official repository and issue-tracker for Enigmatica 6
https://www.curseforge.com/minecraft/modpacks/enigmatica6
242 stars 516 forks source link

redrawNear is slogged down causing stuttrs #998

Open MissPotato opened 3 years ago

MissPotato commented 3 years ago

Modpack version 0.3.7 and 0.3.6

Describe the bug Really long render times due to redrawNear function. I believe a mod is tacking something on rather slow. This is most noticable whenever a block is broken as it causes the 16x16x16 to have to redraw. Fast Leaf decay is the biggest offender for causing the stutter but is not the source of it. While "alwaysSetupTerrainOffThread = true" does allievate the symptoms it is really just a bandaid fix for the larger issue.

From reading the spark report it seems like either a mod calling on CodeChickenLib is at fault or CodeChickenLib is at fault as it's the only additional function as far as I can tell.

Logs https://spark.lucko.me/#TeX3f48HuK

NielsPilgaard commented 3 years ago

Thanks a lot for the detailed report, I'll look into our options for fixing this :)

NielsPilgaard commented 3 years ago

I haven't been able to see any difference with/without CodeChickenLib, and changing alwaysSetupTerrainOffThread to true doesn't change anything for me, so I have a hard time reproducing this observation :/

Darkere commented 3 years ago

What command did you run to get these values?

MissPotato commented 3 years ago

I did /sparkc tickmonitoring to figure out the threshold for an average tick with no block updates. For me it was a max of 33 ms per render frame. Then, with the monitor still running I broke the tree to see how long the stutter frames took to process. They were taking above 100 ms to process for each block broken.

I then ran the command /spark sampler --only-ticks-over 150 to capture only frames that took the longest to render.

Spark's wiki better explains it.

I believe the issue is just more noticeable on weaker PCs, however block update related lag doesn't bode well for late game play as it's often an issue that scales with more things happening. This could also possibly be a networking related stutter as these tests were done on a dedicated server, I haven't tested in SSP.

MissPotato commented 3 years ago

After doing a lot more further testing, and some conversation in Discord I was able to get a better sample of data. https://spark.lucko.me/#hs84YQbYU0

com.simibubi.create.foundation.block.render.ColoredVertexModel.getQuads() is taking 49.11% of render time. Of 14108 ms spent rendering 6928 ms of it was spent on that single function.

I was able to come to this conclusion after Darkere mentioned lighting being slow and that's why they used optifine. And another Dark said they noticed the issue was much worse above ground then it was under ground. I too had noticed this but just though it was because of FLD. I created a large empty room undergound and placed a row of redstone lamps after powering the lamps I had a reliable method of creating the lag spikes. https://i.imgur.com/32uS46r.png (Flipping the lever on or off caused the spikes.)

Using this set up I sampled many more spikes to narrow out some bad information that was collected in the first sample and it seems that is the source. I'll reach out to the devs of Create and alert them of this and see if they can offer any advice.

spark
spark
spark is a performance profiling plugin based on sk89q's WarmRoast profiler.
NielsPilgaard commented 3 years ago

Awesome bug hunting :D