Simple fix:
...
cursor.blink = False // 13% CPU optimization :-)
...
VS Code uses 13% CPU when idle due to blinking cursor rendering
411–420 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#412Earlier quoted context omitted.
Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on…
> Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos cough Blender ...
Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship.
I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE.
Everything is locked away in menus and "perspectives". If you're writing a Java web app - do you want the Java perspective, the Java EE perspective, the Web perspective, or the Debug perspective?
I hear GIMP's no picnic to work with either but can't confirm personally.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#413I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…
Actually, one of the things that's so absolutely incredible about VSCode is that it's both an IDE and a non-IDE. The delightful thing about it is there are no projects. In the future, I hope this happens to all other IDEs out there. I think the notion of a "project" clearly comes from the idea that the source structures must be understood so that proper syntax highlighting, auto-completion, etc... can work correctly. Maybe in this new era of machine learning, our "IDE-less" IDEs can start auto-figuring this stuff out and just know how to build, complete, etc without any of this crazy hassle.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#414Earlier quoted context omitted.
> You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…
There was a big new overhead -- in DOS you could write directly to video memory, and control the graphics cards registers directly. In windows you had to go through libraries. Until DirectX came along, it was basically impossible to write even reasonable performance animations in windows, hence the lack of games in windows 2 and 3.
That is not true, before DirectX there was WinG and there were quite a few good games done in WinG.
The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#415Earlier quoted context omitted.
Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.
> there's a networked file system > a multi-user collaboration engine > a realtime notification system None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay? It's so bad that I often use the basic…
I imagine it would be hard for Google to run integration tests if the whole app took 15 seconds to load instead of 3. Not to mention that if there's an error loading part of it, people will complain that they wrote a document but it wasn't saved/shared like they expected.
Google Docs is truly amazing technology for the browser. It's just bringing its model to "native" apps that I have very mixed feelings about.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#416Earlier quoted context omitted.
Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.
Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...
I really can't reproduce that. I used MS Office since Office '97, and even Office 2000 on a Windows 98 machine loaded in about three seconds. Nowadays, with Office 2010 or newer you won't even see the splash screen anymore. Start menu -> click -> poof, application is there. Google Docs is nowhere near that.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#417Earlier quoted context omitted.
> You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.). Oh, and you also got the benefit o…
> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack. Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!". "Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all eve…
You are forgetting the magic CSS incantations, which are browser and version dependent, to accelerate something that is just granted on any native UI toolkit.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#418I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…
This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner…
Nice foot gun story. If you had a T1 at the time, you would never had noticed such a pitfall.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#419OH GOD NO Adding ANOTHER interpreted language to the pile? Jeeze you guys are crazy. Just STFU and learn C/Go/Java Does ANYONE in NodeJS world care about efficiency? Or does this "plebian" (ew! hacking is not plebian!) hackability trump all other concerns?
I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility. I know C, Java, p…
For me, a big irritation with Python - intermediate bytecode or not - is that foolish small mistakes in formatting, or missing symbols, etc. will only make themselves apparent when the interpreter (or bytecode interpreter) actually tries to run or use them. In some configurations, it can be preprocessed and checked, but the most typical and default use cases for Python do not promote this.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#420I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…
In the early days of working on my current main project, I found that updating a progress bar was slowing the process it was monitoring. Since there were times when it was useful to see near real-time progress, I added added a slider which allows the user to adjust the sampling rate. That slider is affectionately known (by me anyway) as the Heisenberg Compensator. P.S. I have sped up my shit. That process originally…
> Heisenberg Compensator
That's a perfect name, I love it.