Block Event Lag in 1.16 is excessive

Invalid. Your launcher is modified.

No one cares, still the same game, plus it doesn't change the fact that pistons are laggy in 1.16 so your comment is invalid and unwarranted.

Please still try to reproduce this without using a modified 3rd party launcher, if possible, please also provide a download for the world used in the report.

Could this have anything to do with light updates / involve the light engine, lightmap somehow?

Just a very wild guess, but I recall such lag issues with moving and set blocks or structures since many years, and excluding that (also due to fairly more recent changes with rendering) might help a bit (again, no guarantee).

Essentially something in the direction of MC-170010, but potentially I'm completely off here.

Edit: I just saw you got a glass floor, and glass can lag like crazy.
I got first hand experience with that from a relatively recent MC Infinity client with a glass floor dimension, as well as years ago with the Cubehamster/Sethbling map that we playtested back then before its release.

It spawns moving flying machines, and there was also lots of (dyed) glass involved; we fixed the lag back then by adding a roof over the gaming field, and the resulting darkness/shadow by giving the players nightvision.

When you try to reproduce the lag / FPS drop, maybe it'd be good to test in a redstone-ready world, no glass; you can also test with a layer of solid blocks above the testing ground..

Edit 2: There have been issues in the past if 64 blocks or more changed in one chunk in the same tick or something like that; I recall such issues, see e.g. MC-123304 (and MC-108358 was with 32).

In prerelease 4 (didn't test in other snapshots) I get 40+fps with a mob farm that contains a lot of pistons.
But in 1.16.0/1.16.1 with the farm active I barely get 3 fps. If I freeze the game or turn off the farm the frames return normal.

EDIT: Server impact is the same, about 30mspt

EDIT 2: Light updates are not the issue. (Even though light updates are already pretty laggy client-side.) The lag described above is in the nether with no skylight and no light sources anywhere near pistons.

This issue is similar to MC-192134

MC-192134 does not seem to be related.

MC-190891 could have the same underlying issues like this bugpost here (already linked).

Builds that have worked since 1.15.2 (And not 0 tick farms.) suddenly decide to lock up the game clients.

In 1.15.2 you would see the moving Redstone flying machines stuttering but the Game would still be responsive:

https://www.youtube.com/watch?v=dftxbF8U8U4

& 

https://www.youtube.com/watch?v=b6aK0BfuGp8

These now put the game in a free cursor [Not Responding] state during the flying machines transition, the game starts responding after about 1 minute for the doors, but the silo build seems to just crash the game out, too long a non response I guess.

This happens in both single player and with a local server (which is happily ticking away as the game client locks up, not only has it done it to myself but to a friend connected externally too.

Have tested and the server stays running, albeit with update spikes as the flying machines move, once they stop the game clients become responsive again, however on longer delays the game not only goes [Not Responding] whilst the server ticks away it can after a few minutes crash the game client completely, even trying to login bogs down as the rapid piston updates continue.

In my experience is down to the latest client being unable to process rapid server updates as part of the 0 tick farm fixes, this however should not be the case as it's the server that should ignore rapid client updates from 0 ticks, since the 0 tick farms never moved server side (it why they never caused server lag).

The advantage I have is that I have 2 large builds, one which only lags  [Non Responsive] game client for the duration, the other causes the lag crash, and am happy for the devs to take a look for themselves!

I can also confirm this issue as well, compared to earlier snapshots leading up to the pre-releases the performance was similar to 1.15, however in 1.16.1 when running a tree farm that I would get 20fps before, I now get around a 1 frame per minute framerate. 

The issue seems to be due to client side light updates, after some testing. Reducing light so that both block light and skylight are 0 so that lighting updates are not processed at all seems to help tremendously, although the client side performance is still quite poor compared to older versions of the game. 

Makes me wonder if they could fix this with a simple client do not recalculate light in a chunk (or 5/9) where a 0 or 1 tick piston sequence is going off, that would stop the lighting updates for those areas affected, especially as the server seems fine.

The problem is 1.16.1 will still freeze the game client for players outside of the chunks where the updates are happening.

Can confirm for 20w27a

Aha a version of this was caused by client side lighting updates, yes that is brilliant for lamps, I wonder if it could revert to 1.15.2 style listening to the server if more than a set quantity of pistons are triggering, this would allow smaller Redstone Circuits to carry on with lighting updates, and those moving loads of blocks (lots of pistons moving) to ignore lighting updates (preferably from any chunks with moving pistons) until the number of them moving has dropped to lower levels.

My dual sided 8x8 door works fine, even turned into a portal that has 96 pistons total, half of which pulse at the start and the other 48 as it's moving, more than that more than that and it starts lagging with the [Not Responding], Devs & Mods feel free to check the piston count in the lagging areas of my 1.16.1 test world, as listed above.

Working with various piston configurations I have noticed that the rendering of moving blocks has changed since 1.15.2, the animation of the block moving is very smooth and continuous in 1.16 even when blocks are zero ticked, the animation plays as if the block takes 2gt to move however the contraption still behaves as though the block was moved instantly in the case of a zero ticked sticky piston. My guess is that this change to a smoother animation is demanding more computational resources from the client.

This can causes client crashes even with only a few rows of 15 pistons fire in very close sequence. It's a rare event but has happened multiple times so far on a server I play on that uses kelp based observer farms.

@Jeremy is it a full crash or just [Not Responding] client?
If it's the client try giving it a moment and see if it recovers, the kelp blocks breaking along with the piston movement may be causing the same update lag as my hangar door, takes about a minute to recover from [Not Responding]

Still not fixed in 20w30a.. 

Ive seen clients crash with miniscule amounts of pistons I cant fathom how lower end hardware would fare with any amount of pistons, this lag is gamebreaking I know of many people who wont update because of this lag alone.

Confirmed; although on my machine the contraption is very laggy in 1.15.2 as well, it causes visibly worse performance in 1.16.2-pre1.

As far as I can tell this has been resolved in 1.16.2-pre1. In 1.16.1, according to profiling, 50% of the render threads CPU time was consumed with light updates. This was due to a block update limit of 64 in a chunk that would cause a new chunk data packet to be sent to the client which the client would have to relight entirely. This could cause tens or even hundreds of thousands of light updates in a tick that all happened in the render thread.

In 1.16.2-pre1 this limit has been removed, and the server sends delta packets and light updates for any number of block changes. This has reduced light calculations at the client by a factor of 100, from 50% to 0.6% in profiling, and has greatly increased FPS and reduced client side lag considerably.

Nearly all other efficiencies are classic block entity render and render chunk rebuild inefficiencies that have always existed. I'll leave it up to the mods and Mojang if this should continue to be tracked here.

1.16.2 pre 1 is slower than 1.15.2 at moving pistons, the lag is similar just slower pistons on 1.16.2 pre 1

At least the [Not Responding]/Crash of 1.16.1 has gone the way of the dodo for now.

I would like to mention that this was not in fact fixed in 1.16.2 pre-2 and even seems to be worse. Secondly the "fix" for this also broke piston rendering when pistons retract. E.x. https://youtu.be/arJUOTwLbZI

If you think there's still a performance issue, please create a new bug report (if noone else has already done that).

Testing in the latest release, 1.16.2 pre 2, getting very mixed results, it appears to be highly dependent on the clients computer architecture. Personally I have observed better performance than 1.16.1, with my client no longer crashing sompletely using the test setup, however it is no where near the performance achieved in 1.15.2 getting 30 FPS instead of the 57 obtained in the screenshots above for 1.15.2.

Again, like violine said, please open a new report if it still occurs with exact comparisons and potential causes if possible. While I have head over and over again that there are still performance issues since yesterday, no new report about it has been created yet.

For me its better in pre release 2, although not great. 10 fps in pre 1 and 20 in pre 2.