Issue type:

• 🐌 Performance issue

Short description:

im thinking its my mistake, i might have derped something up somewhere, but its definitely ID causing the lag and idk where, please help me figure this out.

Steps to reproduce the problem:

i have a decent sized ID network, with autocrafting and terminals and and i dont know the exact details of whats causing the lag

Versions:

• This mod: 1.1.17
• Minecraft: 1.15.2
• Forge: 31.2.36

Profiler output:

https://spark.lucko.me/#QVoaktTPj6 this is the latest spark report

i believe that mod specified in the info isnt ported to 1.15 yet, any other way to get the .nps file?

Please follow these steps to produce an .nps file: https://github.com/CyclopsMC/CyclopsCore/blob/master-1.12/.github/CONTRIBUTING.md#performance-issues-snail
I don't see enough information in the current report.

GitHub

CyclopsMC/CyclopsCore

Minecraft library mod for EvilCraft, Integrated Dynamics and others. - CyclopsMC/CyclopsCore

That should be it, thanks!

Thanks for reporting!

happy to help :)

umm idk if this the the right info you want, but i tried using visualVm to make a snapshot(do note this is my first time using it so derp alert)
here goes

snapshot-1600532445976.zip

I took a look at this issue. Although I am not able to fix it, but here is what I found:

When config ingredientNetworkObserverEnableMultithreading is enabled, IngredientObserver will try to wait for lastObserverBarrier to finish, which is a task not on the main thread.

/* ... */
try {
    this.lastObserverBarrier.get(1, TimeUnit.SECONDS); // <---- HERE
} catch (TimeoutException e) {
    return false; // Don't start new jobs when the previous one is still running.
} catch (InterruptedException | ExecutionException e) {
// Silently fail on interruptions and concurrent modifications inside the thread.
// Those kinds of errors can happen rarely, but can be safely ignored
// as the whole process will start over again cleanly in the next observation tick.
if (e instanceof ExecutionException
            && !(e.getCause() instanceof ConcurrentModificationException)) {
        e.printStackTrace();
    }
}
/* ... */

https://github.com/CyclopsMC/IntegratedDynamics/blob/master-1.15/src/main/java/org/cyclops/integrateddynamics/core/network/IngredientObserver.java#L155

This task calls IPositionedAddonsNetworkIngredients.getRawInstances() during its execution.

/* ... */
// Emit event of diff
IngredientCollectionDiff<T, M> diff = diffManager.onChange(getNetwork().getRawInstances(partPos.getPartPos()));  // <---- HERE
boolean hasChanges = false;
if (diff.hasAdditions()) {
/* ... */

https://github.com/CyclopsMC/IntegratedDynamics/blob/master-1.15/src/main/java/org/cyclops/integrateddynamics/core/network/IngredientObserver.java#L259

Which eventually calls ServerChunkProvider.getChunk().

The first thing ServerChunkProvider.getChunk() does is to try to join the main thread. Since the task was not on the main thread, it has to wait here, causing major TPS drops.

public IChunk getChunk(int chunkX, int chunkZ, ChunkStatus requiredStatus, boolean load) {
    if (Thread.currentThread() != this.mainThread) {
        return (IChunk)CompletableFuture.supplyAsync(() -> {
            return this.getChunk(chunkX, chunkZ, requiredStatus, load);
        }, this.executor).join();
    } else {
/* ... */

So, in a nut shell, main thread gets blocked by a task that has to join the main thread.

Although I am not skilled enough to fix this issue, but hopefully my investigation can save you some time when trying to solve it.

For now, disabling the config ingredientNetworkObserverEnableMultithreading is a valid work around.

GitHub

CyclopsMC/IntegratedDynamics

A Minecraft mod to take full and automated control of your appliances. - CyclopsMC/IntegratedDynamics

GitHub

CyclopsMC/IntegratedDynamics

A Minecraft mod to take full and automated control of your appliances. - CyclopsMC/IntegratedDynamics

Thanks for looking into this @SCLeoX.
Sounds similar to issues I had before with this observer.

If the chunk loading is done via TileHelpers.getSafeTile, then this may be relevant: CyclopsMC/CyclopsCore@c0a3522

If that code is already being called, then the hack may need some improvements where getChunkAt is called.