4 ms·
That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will h
by Aeolos 6y ago
That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will have to optimize this before we can do Y", which are totally fine and laudable.
However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that.
And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
- webmaven 6y ago> And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field. Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
- yellowapple 6y ago> slow bloated Electron apps - except VSCode which is fast Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :) It's certainly faster than Visual Studio, but it also has far fewer features.