Slashdot Mirror
Blinking Cursor Devours CPU Cycles in Visual Studio Code Editor (theregister.co.uk)
An anonymous reader shares a report on The Register: Microsoft describes Visual Studio Code as a source code editor that's "optimized for building and debugging modern web and cloud applications." In fact, VSC turns out to be rather inefficient when it comes to CPU resources. Developer Jo Liss has found that the software, when in focus and idle, uses 13 percent of CPU capacity just to render its blinking cursor. Liss explains that the issue can be reproduced by closing all VSC windows, opening a new window, opening a new tab with an empty untitled file, then checking CPU activity. For other macOS applications that present a blinking cursor, like Chrome or TextEdit, Liss said, the CPU usage isn't nearly as excessive. The issue is a consequence of rendering the cursor every 16.67ms (60 fps) rather than every 500ms.
Seems like a minor oversight. It will probably be fixed soon, if it hasn't already been.
Microsoft has actually done a good job with Visual Studio Code. It's a lot better to use than, say, Atom or EMACS. It has some great plugins, they're easy to install, and overall it provides a good compromise between a plain text editor and a full-featured IDE.
I'm not going to hold this minor bug against them.
13 per cent CPU. For a blinking cursor. That's... impressive. But not in a good way
This is why coding tests are given during job interviews.
Is it rendering the cursor specifically at 60 FPS, or is it the entire active window? Because I can imagine a good reason for rendering the active window in an IDE every frame.
Pro tip: when rendering an entire window, or an entire screen in a game, you might want to consider "dirty rectangles" and only redraw what has changed.
Using the CPU draws more power than if it were just idle, so it is incorrect to say it does not matter.
File under 'M' for 'Manic ranting'
No, it sounds like the problem is the insane idea of running local code through a web browser. The web itself is probably the most Rube Goldberg-esque way of displaying interactive data and controls to a user (HTML, a backend language like PHP/Java, a client-based language (JavaScript), and then a crappy markup language for style attributes (CSS)). It's understandable how it evolved, but it makes no sense at all to use this for local applications.
Microsoft describes Visual Studio Code as a source code editor that's "optimized for building and debugging modern web and cloud applications.
But then the article goes on to say...
The underlying issue is with Chromium, which is a part of the Electron Shell (Visual Studio Code and others like Atom and Slack utilize this shell in their apps)"
and then...
Google Chrome product manager Paul Irish, posting to a thread on Hacker News, said, "Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work."
The constant unyielding unending march of useless abstraction.
hardware (hypervisor) -> kernel (per process hardware abstraction for userland) -> interpreted runtimes (nodejs/java/.net etc).
That last part is why modern 'apps' are bloated piles of garbage that need multighz machines to be responsive doing things that could be done on a 486 (eg winNT/mirc on a 486 vs discord on a haswell@4.7ghz). The argument is security and ease of development (zomg! cloud!). The former's been readily disproved and the latter sacrifices significant capability and performance. I think we're well past the point of diminishing returns and into the realm of significant drawbacks.
There's a difference between remembering the piece of trivia that is the name a certain environment calls a concept and understanding the concept.
The question becomes: are you looking for a software engineer, a computer programmer, or a trivia expert?
"What is the Liskov substitution principle?"
I didn't know what it was until I looked it up in the article. So basically you want me to remember that some guy came up with a name for using inheritance and if I don't remember it I'm a bad programmer?
Test to see how the person will fit into your team because no matter how great they are if they disrupt how the team works. Then for programming skill and then for things like remembering the exact definition of terms that they could use Google to get.
What is the Liskov substitution principle?
That is a very poor question. It exhibits the common naive programming test that is more of a trivia test, or basically a programming test derived from some old college quiz. Better questions ask people to perform relevant tasks or to discuss relevant problems. For example rather than ask about "Liskov", ask about the concepts involved:
Q. A Square class is derived from a Rectangle class. Function foo has a non-const parameter of type Rectangle. Function foo is called with using a variable of type Square. Is this safe, if not why?
Note that in the discussion they may inadvertently discuss class invariants.
You say that some programmers do not understand or lack certain tools. The same is true for managers, and your hypothetical questions suggest that you may be lacking the tools necessary to conduct technical interviews and evaluations.
The failure to understand anything more than any one level of the stack is the root cause of the problem:
In fact, I'm willing to bet it's not a coincidence that it's 13%. It's likely 12.5%, as in 100% of one thread on a quad-core CPU with hyperthreading enabled, then rounded up to 13% for the presentation in the task manager. On a dual-core with HT, it'd be 25%, on a dual-core without HT, it'd be 50%, and if anyone can get it to run on an old single-core Pentium IV or something it'll just peg that CPU.
People would have to know something about hardware to figure that out, and webdevs, well, they just... don't.
That's because most "programmers" are utter crap. They don't know their tools. They don't know the language that the program in. They don't stay up-to-date.
I don't "know the tools" or "know the language" until I'm fucking using them. Then I google whatever the fuck it is I need to do using whatever the fuck it is some clown has put in front of me, RTFM, and get it done. Interviews test for the dumbest fucking shit. I for one generally don't care what fucking language or environment I'm in. With documentation (the fucking internet 99.9% of the time) learning how to do X in Y is trivial. Knowing that you need to do X instead of x is the trick. When you give an applicant a test to do X in Y, you're just testing if they know Y and maybe if they have memorized X. You're not finding out if they understand anything or can think critically.
They cannot reason about problems. 95% can't do the simplest of problems. You have to really deep before you find people who can talk about design principles, design by contract, etc.
When your "problems" are all pulled from the same "Shitty Questions and Tests for Shitty Interviews" site/book, what do you expect? If you're looking for people who talk about "design principles" or "design by contract", you're retarded. There are only three design principles: Correct, secure, and fast. There is only one design contract: Deliver X for $Y. If you don't understand what X is or why it's X and not x (even if the customer doesn't, or if the customer asks for X when they need x) then you're gonna have a bad time. See Oracle and IBM and anyone who's ever contracted with them.
You're getting mindless applicants because you're asking mindless questions. You cannot discern a competent programmer/developer from an incompetent one because you're looking for memorization, certifications, etc. Of course, the people conducting the interviews are typically not competent programmers/developers, so they don't know what else to look for or how else to evaluate applicants.
Opening VIM is the easy part. If you can successfully CLOSE VIM afterwards, that's the passing point.
Obviously the OP suffers from incredibly lazy thinking to believe that he can find a good candidate with just a couple of questions. You certainly don't want to work there.
love is just extroverted narcissism
This reminds me so much of that rookie question: "what programming languages do you know?"
I dunno, with a reference manual, all of them. It is immaterial because I'm going to have to learn another one for the next project or the next software platform.
And they'll have their own names for common ideas, which you'll see once and realize what it actually is.