back to article 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 …

  1. Anonymous Coward
    Anonymous Coward

    "Anything less than a 60fps cursor is garbage! Go code on an Xbox, peasant!" -- PCMasterRace

    1. Anonymous Coward
      Anonymous Coward

      Joking aside, is it being claimed that rendering a bloody *cursor*- even sixty times a second, which is only high relative to the expected rate- is likely to have any noticeable effect on a modern PC?!

      1. gnasher729 Silver badge

        Most likely it's not rendering just the cursor but the whole screen.

        1. Anonymous Coward
          Anonymous Coward

          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.

          1. gnasher729 Silver badge

            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).

  2. Anonymous Coward
    Anonymous Coward

    but but but

    VS code is supposed to be a lightweight editor.

    1. thames

      Re: but but but

      It's slow and not very useful. I've tried it, but I wouldn't consider switching from Geany.

      1. bombastic bob Silver badge
        Devil

        Re: but but but

        "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).

    2. stanimir

      Re: but but but

      I know of no framework that doesn't claim to be lightweight.

      Javascript IDE, tools and friends, what time to be alive...!

  3. Jonathan 27 Bronze badge

    Do people like VS Code? I personally can't see the appeal, because as an editor it seems a bit slow and heavy and if I want that, I just run Visual Studio (which is much better than VS Code) and if I want light I run Atom or even GEdit or Notepad++.

    1. Mykilr

      I personally use VSCode it for Python because I haven't found a better debugger that is also free.

    2. Anonymous Coward
      Anonymous Coward

      VSCode initially had the best support for TypeScript (given that it's Microsoft's project). Props to them for exposing Typescript Language Services so other editors could quickly add support:

      https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support

    3. Anonymous Coward
      Anonymous Coward

      Yes I love it. It switched from Atom and have never looked back, I find VSCode faster with much better git integration out of the box.

      Using it for Python, node, C# and web development

  4. Anonymous Coward
    Anonymous Coward

    Leave out the cheesy animations from the web

    Most of the time they add nothing, and the relevance rarely translates between tablet and desktop.

  5. Doctor Syntax Silver badge

    The solution -

    vi

    1. P. Lee Silver badge

      Re: The solution -

      >vi

      No need to be a masochist.

      Let them eat vim!

      Er, well you know what I mean.

      1. stephanh

        Re: The solution -

        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.

        1. GrumpenKraut Silver badge
          Boffin

          Re: The solution -

          > (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.

          1. stephanh

            Re: The solution -

            @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.

      2. Bandikoto

        Re: The solution -

        Then you get to enjoy things like trying to read darkblue text on a black background.

        Who wants to read comments, anyway?

        1. Ellipsis
          Thumb Up

          Re: The solution -

          By far the biggest advantage of a syntax-highlighting editor is that it makes comments in source code easier to ignore…

    2. tfewster Silver badge
      Thumb Up

      Re: The solution -

      Obligatory xkcd: Real Programmers

      1. JoeF

        Re: The solution -

        I am wondering if Munroe got the inspiration from the first "Real Programmers" rant: Real Programmers don't use Pascal

        1. stanimir

          Re: The solution -

          >>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)

        2. Zippy's Sausage Factory

          Re: The solution -

          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?

      2. Anonymous Coward
        Anonymous Coward

        Re: The solution -

        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?

        1. Anonymous Coward
          Anonymous Coward

          Re: The solution -

          Because a good IDE makes you much more productive but for banal application made of a few files only? Because it can handle more than text files only? Because it makes debugging and profiling much easier? There is far more in a good application than just typing it.

          1. Anonymous Coward
            Anonymous Coward

            Re: The solution -

            Yes, thank you for lecturing me on the use of IDEs. I want one, there is no company support for them. I can see I should have put a joke alert tag or spelt out that the post contains sarcasm.

          2. bombastic bob Silver badge
            FAIL

            Re: The solution -

            "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)

    3. Dave 15

      Re: The solution -

      only for linux, for real pcs (!) try edlin or debug

      edlin was wonderful and simple

      debug is a bit hardwork but can do a whole lot more fun things

      1. Stuart Castle

        Re: The solution -

        "only for linux, for real pcs (!) try edlin or debug

        edlin was wonderful and simple

        debug is a bit hardwork but can do a whole lot more fun things"

        Pah!

        Edlin is easy.. Real programmers use switches to manipulate the memory directly..:)

        1. Doctor Syntax Silver badge

          Re: The solution -

          "Real programmers use switches to manipulate the memory directly"

          I once read that some IBM system program was written in FORTRAN but after compilation some manual editing of the binary took place. The program as shipped had no corresponding source code.

    4. Phil O'Sophical Silver badge
      Coat

      Re: The solution -

      vi

      My fingers still have EDT keypad commands ingrained in them. I even have a customized version of microemacs where they work.

      Mine's the anorak with the PDP11 in the (large) pocket.

  6. Gene Cash Silver badge

    Heh... I remember one of the optimizations for PROFS on VM/CMS was to turn off the blinking clock in the upper right corner. Freed up 20% CPU on an IBM 4381.

  7. Denarius

    bring back vi and assembler on command lines

    Did not we all use DOS DEBUG to write machine code into .com files once as an exercise ?

    1. P. Lee Silver badge

      Re: bring back vi and assembler on command lines

      >Did not we all use DOS DEBUG to write machine code into .com files once as an exercise ?

      BSAVE <filename>, <start_address>, <length>

      Apple products as they should be!

    2. allthecoolshortnamesweretaken

      Re: bring back vi and assembler on command lines

      FORTRAN 77 on a Control Data Cyber-whatsisname. Using punchcards. In the early 1980ies.

      Just sayin.

      1. Doctor Syntax Silver badge

        Re: bring back vi and assembler on command lines

        "FORTRAN 77 on a Control Data Cyber-whatsisname. Using punchcards. In the early 1980ies."

        Johnny-come-lately.

        FORTRAN IV on ICL 1900 series, punch cards, 1970.

  8. Tom 64
    Paris Hilton

    "13 per cent of CPU"

    What kind of CPU was that tested on, a celeron or an atom?

    A fresh open sees only 3% here

    1. Hans 1 Silver badge
      Paris Hilton

      Re: "13 per cent of CPU"

      What kind of CPU was that tested on, a celeron or an atom?

      A fresh open sees only 3% here.

      I dunno, but if you suspect it's an atom, here, you must have a crap CPU, too!

    2. Dave 15

      Re: "13 per cent of CPU"

      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

  9. Anonymous Coward
    Anonymous Coward

    Rule #1 for the user-facing components development

    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...

    1. Anonymous Coward
      Anonymous Coward

      Re: Rule #1 for the user-facing components development

      I get the point but spare a thought for those poor souls working in full fat Visual Studio on ASP.NET web apps. This approach would guarantee nothing will ever be delivered.

      1. Ken Hagan Gold badge

        Re: Rule #1 for the user-facing components development

        "poor souls working [...] on ASP.NET web apps. This approach would guarantee nothing will ever be delivered."

        You say that like it would be a bad thing.

    2. Ken Hagan Gold badge

      Re: Rule #1 for the user-facing components development

      Why should the developer mind? I have old boxes that I use as test systems for precisely this reason.

      1. nijam

        Re: Rule #1 for the user-facing components development

        > I have old boxes that I use as test systems for precisely this reason.

        Perhaps because there's a difference between making the developers work on an old system, and making them test on an old system?

      2. HieronymusBloggs

        Re: Rule #1 for the user-facing components development

        "Why should the developer mind?"

        Compilation speed?

    3. Patrick Moody

      Re: Rule #1 for the user-facing components development

      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.

      1. swampdog
        Unhappy

        Re: Rule #1 for the user-facing components development

        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.

        1. Anonymous Coward
          Anonymous Coward

          Re: Rule #1 for the user-facing components development

          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?).

      2. PM from Hell

        Re: Rule #1 for the user-facing components development

        From my own experiences as a Tech Support / Ops Manager then PM giving Devs Top end machines then testing on lower powered devices just delays tuning until UAT or even worse production.

        there is a strong argument that devs need a higher powered machine than end users but they need to feel the hit if they are developing inefficient code other wise something which runs a 'bit slow' using test transaction volumes is unusable in production.

      3. John H Woods

        Re: Rule #1 for the user-facing components development

        As a performance guy, I would suggest that it is rather more important that the devs use full size databases etc rather than undersized hardware.

    4. allthecoolshortnamesweretaken

      Re: Rule #1 for the user-facing components development

      Similar sentiments stated here...

    5. Zippy's Sausage Factory
      Devil

      Re: Rule #1 for the user-facing components development

      Which is why I've had bosses ask why I don't want an upgrade to my development machine.

      "But this is one of the oldest machines in the company? Why?"

      "Because if it doesn't work well on here, it's not fast enough. And I don't like writing slow code..."

      1. gnasher729 Silver badge

        Re: Rule #1 for the user-facing components development

        I bought an iPhone 4 on eBay for iOS development exactly for this reason. If it's barely acceptable on that phone, it's fine on a 4s, and fast on everything else. For my development machine, I'd find it totally unacceptable.

    6. swm Bronze badge

      Re: Rule #1 for the user-facing components development

      At Xerox, for the STAR program, programmers needed to build an environment for building and testing the STAR applications so they built the Xerox Development Environment. It ran like greased lightning. The actual product code was very slow because the developers didn't use it and it used structured doodads everywhere.

      Using slow hardware for development means that the programmers will make the software fast.

  10. Douchus McBagg

    why the fudging flipperdy flop, is the CPU giving two patooties about rendering the futher monking cursor?

    this is why you never give the dev team decent kit. makes 'em lazy. if it runs good on a thing from ten+ years ago, it'll hit light speed on a reasonably current machine. and that equals "good user experience"

    how much CPU does a serial link WYSE terminal have to render it's cursor? sweet gravy Winston, if i had 13% of the CPU power of a current thing back then, i'd have been playing quake in 1978 instead of having been eaten by a grue!

    our current dev team have dual socket six core Xeons with gobs of ram and Cuda Cores. makes me want to puke.The business wonders why all their in house apps run like chewing gum on a sun baked sidewalk.

    /Cave Johnson

    1. Dave Bell

      One problem is that the developer environment has bits the user never gets, things like debugging tools.

      There are ways of throttling a machine to see what lower resources, clock cycles and RAM, do to the code . This instance looks more like incompetence.

  11. Buzzword

    I think I see the problem

    > VSC is based on Electron, a cross-platform framework for writing desktop apps using JavaScript, HTML, and CSS.

    There's your problem right there. Who in their right mind tries to write desktop applications using web stuff?

    1. Simon Harris Silver badge

      Re: I think I see the problem

      I read that as based on an Electron...

      the crippled version of a BBC Computer.

  12. nijam

    Flashing cursors are an abomination anyway.

    1. DNTP

      Now tell us how you feel about <BLINK>

      1. stephanh

        blink would have worked

        Actually if the flashing cursor was implemented using <blink>, then there wouldn't be a performance problem.

        Instead, it looks like they are doing full-screen refreshes @60fps to get a cursor to blink every half second, then blame the performance issue on Chromium.

  13. Alistair Silver badge
    Coat

    Kate

    /grabs and runs, the one with KDE for dummies in the pocket.

  14. Dave 15

    yup crappy code from crappy design from crappy requirement

    Who the hell needs a blinking cursor, and who needs one with an option to switch it to solid and a timer for a refresh rate so high....

    *For heavens sake, I buy a more powerful processor with more ram so I can do more USEFUL things (like designing good porn finding programs) and NOT to waste on pointless screen decoration.

    I mean... from what I can see the code needs...

    setup()

    create a timer()

    on timer ()

    go to the options storage area, find the option- probably including parsing some xml these days()

    // yes, done every time in case someone has changed the option!

    check cursor is on()

    if (solid)

    if cursor not on'

    set cursor on

    else

    if cursor not on

    set cursor on

    else

    set cursor off

    retrigger timer if needed by the os design

    ffks sake really, all this for something I don't need, and all the potential security holes as well (i.e. make sure the option code is good etc etc etc)

    And then the writing the code for the setting and clearing of the option

    No wonder modern computer code is slow, shit, bloated and requires gigabytes to print hello world on the screen

  15. Badvok
    Mushroom

    Microsoft vs Apple - ding, ding, seconds out ...

    Only appears to be a problem on macOS

  16. Bryan Hall

    Blitter anyone?

    Sigh... we used to have hardware blitters to take care of this crap without using CPU resources.

    1. allthecoolshortnamesweretaken

      Re: Blitter anyone?

      "Ohne blitter ist es bitter!"

      (That's one of the lines we used on the one guy that had a Ti99 instead of a C64 or Amiga like, well, everybody else... Sengo, if you read this, sorry. But then again, you always kinda asked for it.)

  17. Louis Schreurs BEng
    IT Angle

    Notepad The Winner

    I always use Notepad to script or code.

    But then again, I never do script or code.

    1. stephanh

      Re: Notepad The Winner

      That is almost Zen.

  18. Anonymous Coward
    Anonymous Coward

    NANO

    Runs well on everything. That is all.

    If im feeling particularly hardcore ill just pipe to a text file.

    I generally only use something more advanced if im reading someone elses code especially if im unfamiliar with their coding style.

  19. Stuart Castle

    In the past, when I've done development work for work (which, admittedly, didn't go beyond utilities we needed for given tasks, so was never anything massive), I've always used two machines. I used a relatively fast one for development, as I usually code in C++ and most c++ compilers (especially Visual Studio, although I prefer not to use that) do really benefit from a fast machine with a lot of memory (although it seems to be the memory that generally provides the most benefit). For a test machine, I used the oldest, slowest machine I can find.

    Why? The users that actually used the little apps and utilities I wrote were not likely to have had the latest and greatest CPUs and Graphics Cards. They would not necessarily have masses of memory in their machines. I needed to see what the users were seeing.

    Reminds me of a story I heard about George Lucas. Apparently, when he had finished Return of the Jedi, he went to a local cinema to see it. When asked why, he replied that he had only seen it in Hollywood screening rooms, which always have the best projection and sound systems, and screens. He wanted to see what the man on the street would see when he watched it. Apparently, he was appaled, and that did lead to the formation of THX.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019