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

Integrated Terminal Performance Improvements

code.visualstudio.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Integrated Terminal Performance Improvements

#41

Post by epicide »

nwienert wrote: post #35
w0utert wrote: post #22

Earlier quoted context omitted.

My setup is just the official, latest release, with the Microsoft plugin for C++, the Vim bindings everyone uses, and one additional plugin for switching between header and source. I customized nothing besides a few keybindings and enabling neovim mode. This is on Ubuntu by the way. I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for…

Look at the past threads for releases (I wont link, but) they are filled with nothing but praise. I'm totally non-affiliated with VSCode, but switched from Atom a few months ago and yes, anecdotally it's been an amazingly smooth experience. I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps. To be honest, I really think people have an emotio…

I am floored at how eloquently you've put every single one of my thoughts on the matter. Seriously, bravo (and thank you because I will inevitably quote you).

Re: Integrated Terminal Performance Improvements

#42

Post by epicide »

Waterluvian wrote: post #19

What's the case for using the terminal in VSCode? I use a modern multitasking computer where VSCode is in one area or screen and my terminal in another (and other things in others). By using my own terminal I get to keep everything custom about that terminal rather than having another one. Surely there's reasons that I'm missing? Edit: thanks for all the responses. A lot of great new things I didn't think of before!

As someone who regularly has several browser-based projects open, it's nice having a small part of the window that shows the current progress of the build.

I've gone back and forth using a "normal" terminal and using the one in VSCode. I often end up using the latter since it keeps the build progress with the proper project.

Having the project folder as the CWD automatically is a really nice time saver, too.

Re: Integrated Terminal Performance Improvements

#43

Post by styfle »

helloimraghav wrote: post #39

I'm an iOS Developer learning React, using Webstorm I can get all the auto completion + some other things I like from Xcode. Can I set up VS Code to do the same?

I don't have experience with React Native, but certainly React + TypeScript gives you autocomplete in VsCode.

Try cloning my repo here:

https://github.com/styfle/react-server-example-tsx

Re: Integrated Terminal Performance Improvements

#44

Post by Zaskoda »

revelation wrote: post #14

That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator . The Electron waters are shallow and when you jump in head first you might hit a performance wall sooner than your feet hit the water. I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.

I don't think it's entirely fair to say that they had to drop down. I suppose that all comes down to what you mean by "acceptable". Personally, I think they chose terminal rendering as something to optimize and I think it's a great choice. You emphasized "terminal emulator" in your comment. I don't think they chose to optimize the terminal because it was new ground, but rather because it's a well understood problem space. The Electron waters are limited, yes. But I think it's nice to see developers pushing at those boundaries, no?

Re: Integrated Terminal Performance Improvements

#45

Post by revelation »

WorldMaker wrote: post #40
revelation wrote: post #14

That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator . The Electron waters are shallow and when you jump in head first you might hit a performance wall sooner than your feet hit the water. I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.

Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful. VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (…

That was done because it was the only method available or because they started out with high performance / low latency / ... goals. Here is the VS Code team saying DOM performance was useless. And at the end of the day we're talking about 80x20 characters, sometimes color.

Re: Integrated Terminal Performance Improvements

#46

Post by WorldMaker »

revelation wrote: post #45
WorldMaker wrote: post #40

Earlier quoted context omitted.

Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful. VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (…

That was done because it was the only method available or because they started out with high performance / low latency / ... goals. Here is the VS Code team saying DOM performance was useless. And at the end of the day we're talking about 80x20 characters, sometimes color.

No, the VS Code team is saying DOM performance isn't enough for the high performance / low latency demands they are seeing.

The performance with DOM was already good enough for all my needs, personally.

They had a lot of people wanting 60fps consoles, so they decided to take a 60fps approach, and even though it is "just" text/color/limited graphics, it shouldn't be a surprise that the 60fps approach is the same one they would take for a more graphics-focused approach somewhere else.

Re: Integrated Terminal Performance Improvements

#47

Post by santaclaus »

nwienert wrote: post #35
w0utert wrote: post #22

Earlier quoted context omitted.

My setup is just the official, latest release, with the Microsoft plugin for C++, the Vim bindings everyone uses, and one additional plugin for switching between header and source. I customized nothing besides a few keybindings and enabling neovim mode. This is on Ubuntu by the way. I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for…

Look at the past threads for releases (I wont link, but) they are filled with nothing but praise. I'm totally non-affiliated with VSCode, but switched from Atom a few months ago and yes, anecdotally it's been an amazingly smooth experience. I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps. To be honest, I really think people have an emotio…

> it's a no-brainer to choose JS for just about any complex UI

Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times that aren't measured in seconds. Or an Electron-based text editor that doesn't choke on a moderately sized text file. VS Code is currently taking half a gig of ram on my notebook with three text files open...

I happen to quite like VS Code, but to claim that Electron is a no-brainer is simply false. There are serious tradeoffs.

Re: Integrated Terminal Performance Improvements

#48

Post by chillee »

dy wrote: post #13

Love the integrated terminal in VS Code! Great work by the team on this and appreciate the writeup. Curious what keyboard shortcut people use to move focus from editors to the Terminal and create new terminals? Anyone use tmux inside terminal?

A big thing that I use is that if you do quick open (`ctrl+p`) and then type `term `, you can then type the terminal number to go to the specified terminal.

Re: Integrated Terminal Performance Improvements

#49

Post by chillee »

w0utert wrote: post #22
CJefferson wrote: post #12

Earlier quoted context omitted.

Something is seriously wrong with your setup. I know many vscode users, and none of them are having your problems. I'm not saying you aren't having real problems, but they aren't common and they can appear in any editor -- I used to fill vim with plugins and it would hang frequently.

My setup is just the official, latest release, with the Microsoft plugin for C++, the Vim bindings everyone uses, and one additional plugin for switching between header and source. I customized nothing besides a few keybindings and enabling neovim mode. This is on Ubuntu by the way. I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for…

Could you elaborate on what you mean by "the vim keybindings acting up"?

Re: Integrated Terminal Performance Improvements

#50

Post by lobster_johnson »

w0utert wrote: post #11

I really wish Microsoft had used a different platform to build VS code on, like C#/Mono, Java, anything except Javascript/Electron basically. I just started using VS code for C++ development, trying to switch from Vim, an I basically like everything about the concept, but the execution and quality/polish of the software is mediocre at best. At least three times a day random stuff breaks: code completion stops working…

I'm much happier than you, but I concede there are some rough edges, especially related to extensions.

In particular, ESLint and the Go extensions randomly cause problems for me. I often lose JS autocompletion and linting; no errors, just stale or missing markers and only fix is to restart the window. Often the Go completer or "go vet" or whatever goes bananas and gets stuck taking 100% CPU. Often a random "Code Helper" sits taking 100% CPU for no discernible reason. Sometimes the Helper mysteriously gets better after a few minutes.

I can always work around these issues by restarting stuff. The main problem is that I can never report anything cogent based on this misbehaviour, because I have zero visibility into what is causing them; for example, as far as I know VSCode doesn't have a "task list" for its async operations (such as indexing, linting etc.), so there's no way to correlate misbehaving child processes with those operations like you can do in Chrome. I once submitted a Github issue with dumps (macOS process traces) when a Code Helper process had sat at 100% for an hour, but the VSCode team said it wasn't helpful, but they also didn't offer any way to actually trace the problem. There are also no logs as far as I can tell.

Admittedly, often it is extensions or external tools that misbehave, not VSCode, but the above remains true -- without any visibility there's no way to fix.

For all that, VSCode is the best IDE I have had since I was a Java developer using Eclipse around 2006 or so. VSCode doesn't quite reach that level of integration (for example, Eclipse had instant incremental compilation built in, whereas in VSCode linters are for some reason dumb and stateless and have to potentially look at your entire project every time you make a code change, which is the opposite of instant), but it's getting there.

Post reply on HN