Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VS Code uses 13% CPU when idle due to blinking cursor rendering

github.com

Post reply on HN
Print view View original

791–800 of 801 posts

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#791

Post by abritinthebay »

szatkus wrote: post #269
abritinthebay wrote: post #151

Earlier quoted context omitted.

VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...

Wait, why? I use Atom on daily basis, don't have very strong machine, but I've never seen performance issues.

Compared with Sublime Text (what I used before VS Code) Atom was painfully laggy and slow.

Now if I was coming from a larger, probably Java, IDE? Yeah, I can see that Atom would look great.

Just wasn't for me. Glad you like it tho!

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#792

Post by joshwcomeau »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

I really like that I can edit my editor. A few times, I've disliked how something looked or wanted to add a feature. So I tweaked the stylesheet, or wrote an Atom plugin.

There's a beautiful poetry to being able to do web dev inside a web application.

I still have Sublime text for when I need to view/edit files with tens of thousands of lines, since Atom chokes on large files, but otherwise I have zero regrets :) I'm as productive in Atom, and it's a more pleasant experience.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#793

Post by nonsince »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

Agreed. If you're looking for easy extensibility, a simple core and a flexible GUI, I can't imagine what could put VSCode above emacs, except for the button marked "sort by CPU usage"

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#794

Post by squeaky-clean »

JdeBP wrote: post #580
squeaky-clean wrote: post #507

Earlier quoted context omitted.

My whole point is that "most used" is a terrible, terrible metric for anything except for most used.

Not even for the market "voting with their downloads"?

Ctrl+F "voting with their downloads"

1 post found.

Oh, this comment.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#795

Post by joshuamorton »

tomc1985 wrote: post #519
joshuamorton wrote: post #491

Earlier quoted context omitted.

that was a typo. "not-interpreted" was my intended statement. And I'd love for you to show me a python variant that is compiled in the same way that C is compiled. The closest is nuitka, which...isn't.

cpython? I know the regular python-2.7 installer in debian does binary compilation, producing little *.pyc files for everything

As the other user mentioned, those are compiled in the same way java is compiled, but not in the same way that C is compiled. They still need an intermediate VM to run.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#796

Post by ryanpepper »

uzoodoo wrote: post #343
ryanpepper wrote: post #314

Earlier quoted context omitted.

Yeah, but Qt has licensing costs for commercial use...

Qt is LGPL, so unless you need to link to it statically or make proprietary modifications to Qt itself, you don't need to pay licensing costs.

Ah right, I wasn't aware of that.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#797

Post by jblow »

trishume wrote: post #780
jblow wrote: post #765

Earlier quoted context omitted.

"so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets." Immediate mode GUI systems are allowed to keep state around between frames and the most-featureful ones do. The "immediate mode" is just about the API between the library and the user, not about what the library is allowed to do behind the scenes. The argumen…

I'm definitely aware of this, it's why I mentioned "varying levels of caching". The Conrod imgui that I mentioned basically uses retained mode GUI data structures behind an immediate mode API through diffing for performance reasons. This works just as well/quickly as a retained mode API in almost all cases. There's some cases like extremely long tables with varying row heights and sortable columns, where you need an…

"I'm curious what API you would use for implementing a table with varying row heights (that you only know upon rendering but can guess beforehand), sortable columns and millions of rows."

In general my policy is that when things get really complicated or specialized, the application knows a lot more about its use case than some trying-to-be-general API does, so it makes sense for the application to do most of the work of dealing with the row heights or whatever. (It's hard for me to answer more concretely since it depends on exactly what is being implemented, which I don't know.)

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#798

Post by skc »

flukus wrote: post #599
skc wrote: post #579

Earlier quoted context omitted.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane. That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.

A WPF app is just a .Net app. I can't recall the problem described ever having been an issue.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#799

Post by wtetzner »

pcwalton wrote: post #323
ksk wrote: post #305

Earlier quoted context omitted.

Do you want to listen to the reasons, or just tell them to "go make your own if you don't like it"? You can't have it both ways. I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model o…

> Which also explains why there isn't even a reference implementation. As someone who has spent years implementing those standards, a reference implementation would not help me at all. > As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI. Dear imgui's layout model doesn't scale at all, due to the fact that it's immediat…

> Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Which isn't a problem if you're layout algorithm is fast/simple. If it's not, then it's a bigger issue.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#800

Post by androbabu »

RebeccaTheDev wrote: post #395
artursapek wrote: post #25

I'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…

Your story reminds me a current scenario @peckrob ..

For Android Application development, we used to connect devices to computer via usb and would see the device's log in logcat tool (Android Studio). The device, in general, spawns lots of logcat messages during a debugging session and would eats up CPU.

The case is still worse that the tool stucks when device is connected over wifi (wifi-adb) as the data transfer is little lower in wifi than usb.

Post reply on HN