Unfortunately I didn't dig too far into which optimizations of FastCraft's it was messing with - it seems to be more than just the light tick update stuff that gets overridden below. On the client side (with FastCraft) the lag was inside the renderer.EntityRenderer call tree, but nothing in there stood out as being EBXL's fault unlike on the server.

On the server side (with Cauldron), the mess is inside the WorldServer.func_147456_g call tree. It takes up roughly 90% of the server thread while doing worldgen with ExtraBiomesXL installed, 10% with it removed.

JVisualVM Screenshots. With ExtraBiomesXL

Without

Thanks.

I think this is caused by the OnUpdateTick code in BlockGreenLeaves. The purpose of the override was to extend the distance leaves could be from a log to prevent decay. The increased distance adds to the time spent checking for logs and the override avoides optimazations made by cauldron and fastcraft.

Recommend removing OnUpdateTick override and changing tree geometry to place strategic logs so that all leaves are within the standard 4 block range to prevent decay.

I think this is caused by the OnUpdateTick code in BlockGreenLeaves. The purpose of the override was to extend the distance leaves could be from a log to prevent decay. The increased distance adds to the time spent checking for logs and the override avoides optimazations made by cauldron and fastcraft.

Recommend removing OnUpdateTick override and changing tree geometry to place strategic logs so that all leaves are within the standard 4 block range to prevent decay.

—
Reply to this email directly or view it on GitHub.

Once every leaf block has been checked, won't it then be "stable" until a block update causes things to change?

I know that when vanilla jungles generate, each leaf has to be checked, and you get invalid leafs decaying. But once checked, a given leaf block doesn't have to be rechecked. Eventually, (my understanding), when a leaf block gets a neighbor update, it resets the "must check for suport" flag, which in turn notifies it's neighbors.

...

Which, now that I think about it, could spread very, VERY far in jungles, or roofed forests. Is that actually how things work?

In the screenshots above, it was from a Redwood Forest biome, but yes, it basically results in a cascade of block update checks until it eventually settles (though I've seen it permanently lock the server occasionally).

FastCraft doesn't optimize block ticks directly since that'd change observable behavior/game play.

There's nothing in ExtrabiomesXL disabling any optimizations either. It just has much heavier world gen like any other mod in this area. It could potentially check leaves against its own decay rules before placing them, but that's not what anyone else does either as far as I'm aware.

Replacing Cauldron by FastCraft on your server or at least pre-generating the world around spawn would probably help getting rid of the lag.

So considering that Cauldron's ticking changes are rather bogus to start with and FastCraft not being harmed at all, the original complaint in the subject is a bit misleading...

He's a profile of BoP in a similar situation on Cauldron:

So 20% in BoP with heavy forest terrain (Coniferous Forest here).

Similarly, I can't seem to replicate the severe, gradual-onset lag that occurred in FastCraft (not in Cauldron) when I had ExtraBiomesXL installed. There's still some in BoP, but it's far more intermittent and goes away when I move.

Thanks for clarifying, @sfPlayer1