Input polling rates drastically decrease editor performance and is responsible for causing the majority of stutter in the editor
1. What happened
Keyboard and Mouse events such as MouseMove and MouseDrag gets piled up, preventing editor views from repainting and dedicating resources to more important things such as actually rendering the scene. In some cases it takes 30+ GUI before it gets to render the frame, taking up most of the resources in order to render pretty much nothing. (see examples below).
This issue explains why newer versions of Unity has always felt laggier compared to older ones.
I'm not sure when this started happening but tried it in 5.3 and the most I could get out of it there was: "Layout, MouseMove, Layout, MouseMove, Layout, Repaint." I'd guess it was introduced in late 2017, not entirely sure.
Here are the results with a mouse that has a polling rate of 1ms / 1000hz, (which is the default of mine)
After lowering the polling rate from 1000hz to 125hz, it looks like this:
And here it is at 250hz:
It's also interesting to see that if I pretend to do a lot of work (Thread.Sleep(13)). It doesn't pile nearly as many events up during a frame, which means some sort filtering is already happening, but the editor could run so much smoother if this got optimized.
Here is a video demoing just how much lag is introduced which could be butter smooth if this issue was addressed: https://www.youtube.com/watch?v=Mb795VPhi0M
2. How we can reproduce it using the example you attached
1) Move the mouse in the SceneView, and observe how many events it takes to draw a single frame.
2) Open the context menu "Editor Window Polling > Test" and observe the same issue.
You can somewhat measure the polling rate of your mouse here: https://zowie.benq.com/en/support/mouse-rate-checker.html
Online discussions about the issue can be found here:
License type: Free