Blinking cursor devours CPU cycles in Visual Studio Code editor 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 per cent of CPU capacity …
Ah yes, I should have read closer- "Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval."
Still, how much of that is necessary? And even at 60 times per second, I wouldn't have thought a text editor screen update would use 13% of the CPU time.
Here's a possibility: At some point the screen was updated twice a second (or when you typed), so that used 0.4% CPU time, and nobody cared how efficient or inefficient the actual drawing was. It was inefficient, but who cares if it's 0.4% CPU time inefficient?
Then someone was careless and introduced 60 updates per second. Now the inefficiency hurts. (Of course nobody will work to make the screen updates twice as fast, if you can just set the updates back to twice a second and save a lot more CPU time).
"It's slow and not very useful. I've tried it, but I wouldn't consider switching from Geany."
I just use pluma (or gedit if gnome 2 is installed). Works well enough, highlights code elements, few irritating features (other than having to occasionally strip ending white space off of code lines, but a lot of editors cluelessly let that happen these days...) and it DOES NOT HAVE PERFORMANCE ISSUES that I can tell (even in a VM).
One of the many things I like about Vim is that it is so fast. "vim foo.c", bam, the file is there, no loading screens or other nonsense. You search for something, bam it is there. Syntax highlighting never takes a coffee break (et tu, Emacs?).
Non-bloated apps like Vim are great. They make you actually get to profit from faster CPU speed.
I tried Visual Studio Code once for kicks and it was like typing in treacle.
> (et tu, Emacs?).
The memory footprints of Emacs and vim are virtually identical (try it!). Things like the splash screen can (and should) be disabled in Emacs.
The one situation where I find Emacs lacking in performance is for very large text files (hundreds of megabytes). And even that can be (mostly) fixed by disabling, line-number-mode and syntax highlighting if the file is larger than some threshold of your choice.
@GrumpenKraut
I have no qualms with Emacs memory usage (and a quick "top" shows you are indeed right about comparable memory usage.)
I switched from Emacs to Vim around 2000, at that time I recall that Emacs tended to be sluggish in syntax highlighting, especially on larger files. Perhaps faster CPU or performance improvements in Emacs have made the issue moot by now.
I am wondering if Munroe got the inspiration from the first "Real Programmers" rant: Real Programmers don't use Pascal
>>I am wondering if Munroe got the inspiration from the first "Real Programmers" rant: Real Programmers don't use Pascal
Obviously it a reference. I recall this paper when I was a kid (like 10)... good stuff -- still recall quotes and some of the them a partly true (like arrays and datastructures)
I am wondering if Munroe got the inspiration from the first "Real Programmers" rant: Real Programmers don't use Pascal
Or The Story of Mel?
In our company they actually use vim but don't tell them about the flapping butterfly method or someone will propose it as a cost saving.
Why would anyone want to use an IDE? That takes time to set up, time that could be better spent eking out code on vim. Hell, not even ctags works thanks to crazy includes. But why would anyone want ctags when we've got grep?
"Because a good IDE makes you much more productive"
which is why I've been working on one, off and on, for several years [using native X11, meaning a simplified C language toolkit to manage basic UI elements]. money would make it go faster.
Until then, there's pluma (or gedit on gnome 2) for the code, gimp for graphics images, and 'whatever tool' (including hand-coding) for HTML and dialog layouts. When you look at the older Visual Studio versions, where hot-keys quickly got you to the thing you needed to change something on a dialog box (or add a variable, let's say), the IDE _WAS_ more productive. Since 2000-something, though, it's gotten all "property sheets" and "mousie-clickie-mousie-clickie" where it JUST! GETS! IN! THE! WAY!!!
in short: if you have to remove one hand from the keyboard to operate a mouse more than a few times per hour, there's something wrong with the IDE.
And DevStudio is one of the _WORST_ at that (post DevStudio '98 anyway)
ONLY, ONLY, ONLY.... Only 3% is precisely 3% more than shoudl be wasted on such crap
Really, I don't care if it is 13, 3 or even .0000003 it is extra crud that adds nothing useful and should not be present. It also adds to loading time, causes more memory page errors and use of cache etc etc etc
We used to have a rule saying that the developers working on the user-facing components (such as editors, data input, visualization tools, and other data presentation) should be allocated the slowest systems their users might be running. This tends to result in the code which works well for all users.
Obviously, the developers in question tend not to like this approach very much...
I think the developer should have access to all the computing horsepower he/she desires (within the employer's budget) but that testing/debugging should be done in a deliberately crippled virtual machine. This way the actual development tools will perform well on the high spec workstation, but the application produced can be seen to work well enough on a low spec end-user's machine if it does so in the low-end virtual machine instance.
I couldn't agree more. I was once tasked with making an aix system "linuxy". The first issue was to build a reliable gcc because the freeware gcc would crap out on large builds, spuriously producing object files with no code inside. Now, they could have given temporarily given me a (then new) unprovisioned power 6 box (destined to become a new oracle server) but instead some wag with the ear of those above trotted out that "give the devs crap" twaddle. I got instead, a standalone dual core power 5 box with 1G ram and iirc it would take upward of 40 minutes to build gcc 4.0.2 - except it didn't because of the afore-mentioned freeware gcc bug. There was about a weeks worth of debugging to get an initial, reliable gcc built but actual time spent was more than two months.
I got instead, a standalone dual core power 5 box with 1G ram and iirc it would take upward of 40 minutes to build gcc 4.0.2 - except it didn't because of the afore-mentioned freeware gcc bug. There was about a weeks worth of debugging to get an initial, reliable gcc...
You should have invested couple of hours into reading the gcc installation manual. The SOP in cases where the native cc was missing or broken was to first build gcc as a cross-compiler on a different system, then use the cross-compiler to build stage1 for the target. This was a bit more work than the all-native installation (you also need to cross-build binutils and a few other bits), but it works very well. I used this technique to build gcc on several POWER3 and POWER4 AIX boxes far less capable than the one you describe; I do not remember it ever taking more than a day (with an overnight final test-case run judiciously thrown in - but that does not count as my time, does it?).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
