My E2E-E server run with 9 people.

I noticed ~3% TPS caused by Thaumic Augmentation when profiling with Spark:

https://spark.lucko.me/dgYOuB47ke

debug.zip

As far as i get from source code, this part of TA somehow handling warding or something.

• Is there any way how i could get rid of this lag?
• Maybe there is some kind of blocks that causing it?
• Is it possible to disable a feature if nothing else helps?

The CF launcher is what confused me

That event handler is for stopping scheduled ticks on warded blocks. The intention behind blocking them is so that they don't change themselves into something else or otherwise react to their environment. As an example, this is how you can ward something like a redstone repeater and have its output not stop. To directly answer your questions:

• There is no way to really reduce it, short of either me changing the code to either not do that anymore or do it more efficiently. Doing it more efficiently is possible but will take some work.
• It has to go through that loop for each block that has a scheduled tick, which there can be a lot of.
• There is a config option to disable warding - disableWardFocus. That will stop that event handler from running at all, but of course you will lose the feature.

Thank you for answer!

As far as I know disableWardFocus would completely disable whole warding mechanics? Can you make configurable option to just disable this "scheduled tick" mechanic?

Thank you for answer!

As far as I know disableWardFocus would completely disable whole warding mechanics? Can you make configurable option to just disable this "scheduled tick" mechanic?

A bit late, but the answer is yes. I added a config option that disables what are IMO the biggest potential offenders for performance, since I think some may be worse than others depending on the modpack. They are:

• Scheduled tick events (your issue)
• Random tick callbacks
• Neighbor block update events

Would that be ok with you?

Probably would be good.

I would request that you release this fix, as it's eating my in-progress modpack alive on a fairly beefy CPU. It comes and goes, but when it appears, it eats upwards of 60 milliseconds on its own.

Do you mind sharing a trace of when that happens? If you don't want to share details about your modpack, just the relevant section is fine. 60ms is very much in "fix ASAP" territory. I might just have to do the more difficult optimization I mentioned before now.

Upon testing the modpack in a server setting, the issue seems to go up exponentially per player, ~60ms worst case for singleplayer, ~145ms for two, and ~320ms(!!) for three, even if they're in the same location. The only logged symptoms are that the game takes 30 minutes or more to stop the aura threads after saving and exiting (the map is saved before this, so it's safe to kill the game/server at this point) and just generally not being able to keep up. I'm not near my machine at current, I'll post a trace the next chance I get.

I'm still interested in that profiler trace, but are you sure it's the same issue? I'll fix it regardless, but I wouldn't expect this tick handler to grow based on player count like that unless they were all separated.

While waiting on my small group of testers to be available for proper traces, i've noticed that (in singleplayer at minimum,) once the ward effect is unlocked and the save is reloaded, the problem disappears, but removing the research with the thaumcraft debug commands and reloading again makes it reoccur. Looking at relevant source, I have no idea why that's happening, but my understanding of Java is limited at best. I will provide traces once I can coordinate a test that can properly show the issue with multiple people.

I would request that you release this fix, as it's eating my in-progress modpack alive on a fairly beefy CPU. It comes and goes, but when it appears, it eats upwards of 60 milliseconds on its own.

I would request that you release this fix, as it's eating my in-progress modpack alive on a fairly beefy CPU. It comes and goes, but when it appears, it eats upwards of 60 milliseconds on its own.

Do you mind sharing a trace of when that happens? If you don't want to share details about your modpack, just the relevant section is fine. 60ms is very much in "fix ASAP" territory. I might just have to do the more difficult optimization I mentioned before now.

I would request that you release this fix, as it's eating my in-progress modpack alive on a fairly beefy CPU. It comes and goes, but when it appears, it eats upwards of 60 milliseconds on its own.

Do you mind sharing a trace of when that happens? If you don't want to share details about your modpack, just the relevant section is fine. 60ms is very much in "fix ASAP" territory. I might just have to do the more difficult optimization I mentioned before now.

Upon testing the modpack in a server setting, the issue seems to go up exponentially per player, ~60ms worst case for singleplayer, ~145ms for two, and ~320ms(!!) for three, even if they're in the same location. The only logged symptoms are that the game takes 30 minutes or more to stop the aura threads after saving and exiting (the map is saved before this, so it's safe to kill the game/server at this point) and just generally not being able to keep up. I'm not near my machine at current, I'll post a trace the next chance I get.

Thanks!

P.S. CF beta file have wrong changelogs.

Thanks!

P.S. CF beta file have wrong changelogs.

Which part of the changelog is wrong? It looks ok to me - are you looking at the right file? Since this is a beta update, you have to go down to the file list and select it, since the big suggested file at the top will only ever be releases updates. Here's the direct link.

Oh, my bad. You right, I checked wrong file. Sorry.

The config option itself was released in the latest update (check the beta files on CurseForge). Optimization is planned for the future after I complete some other coremod infrastructure work. @ParzivalWolfram, if you ever get that trace feel free to open another issue, as it sounds different from this one.