Improved performance makes it even easier to use! Visual Studio Code 1.19 released!

Hello.
I'm Mandai, in charge of Wild on the development team.

I was relieved to have just finished my first writing project in my life, but then I realized that a Visual Studio Code (VSCode) update was long overdue!
While I know it's a little late, let's take a look at this update!

As usual, it's not comprehensive, but I've narrowed it down to features that would be useful for developers to know.

 

It's not flashy, it's performance

There are no eye-catching new features in the 1.19 update, so I think the main topic is the performance improvements.
The understated nature of 1.19 really stands out, especially since 1.18 was a big deal.

It seems that they have focused particularly on improving startup performance, and the improvements include the following:

• Startup and configuration performance improvements
• Improved performance by retrieving extension information from package.json during startup from cache
• Improved performance by delaying the launch of helper processes at startup (for processes like file watchers, file searches, and extensions)
• Improved file loading for faster startup
• Reworked the breakpoints view and explorer pane to use a faster list widget instead of a tree
• Improved performance by adjusting touch event handling
• Improved performance across the workbench by skipping unnecessary layouts and calculations that are not used
• Improved performance by removing code not used for startup

I have experience with refactoring to improve performance, but it's a mundane task.
The sense of self-satisfaction when your improvements work perfectly is incredible, but most of the time it's just dismissed as "it's faster now," so it's often unrewarding.

That's why I understand how important an improvement this is! (Actually, I want to understand!)

 

There are a lot of command line arguments

I mostly use VSCode on Windows, so I haven't used it much, but you can also launch it from the command line.
For example, on Linux, you can type "code" into the terminal and the GUI screen will launch (I was a bit shocked that there wasn't a command called "code").

The "--status" command line argument has been added, which displays VSCode version information, resource information (this displays CPU usage and memory usage for each running process, as well as the parent-child relationships of processes), and workspace status. I haven't found
a situation where I needed this kind of information in everyday use, so I think this is a feature mainly for extension developers.

The --status option seems to have another feature, which is to display the resource usage of each VSCode process in the debug pane.
However, this feature does not seem to be included in the official version, and requires the addition of a module available on github.

In addition, it seems that it is now possible to pipe stdin (standard input) from the command line and have the piped information flow into the launched editor

I wondered if this could be used for error logging or something, but the mechanism for dumping logs to a specific file is a standard feature when using frameworks, so perhaps it's used when fiddling with shell scripts. I
can't think of a use case for it, so I'll keep this feature in the back of my mind and hope to boast about it someday.

This is completely unrelated, but speaking of logs, when you're working with a log file open, the content in the editor will be updated when the file is watched, but it would also be great if the display position could follow the end

 

Workbench tab behavior has changed

The "workbench.editor.tabSizing" setting has been added to settings.json.
This setting controls how tabs are displayed when multiple editors are open, and has two modes:

• fit
• shrink

If you select "fit" (the default), the tabs will not be smaller than the size that will ensure their titles are displayed.
The problem is that if the number of tabs increases and they cannot all be displayed, the oldest tabs will (probably) disappear, and you will have to use Ctrl + Tab

If you select "shrink," the tab size will become infinitely smaller, but as the number of tabs increases, the text will no longer be displayed and only the close icon will be displayed. If
you are confident that you can distinguish tabs even if only the first few characters are displayed, Ctrl + Tab a hassle, we recommend selecting shrink.

By the way, I'm also a shrink user.
However, if you hover the mouse cursor over the tab for a few seconds, the full path of the file will be displayed, so it's not that much of a hassle.

 

A simple but useful clipboard and file comparison

Added the ability to compare strings in a file and the clipboard

If you want to compare a file in another branch uploaded to GitHub with a local file, you can copy and paste the code from GitHub and compare it with your local file without having to prepare the file one by one.
The above is a case where I actually used it, but I feel like there are other uses as well.

 

IntelliSense has gotten smarter

Even if you type "return" as "retun," IntelliSense will still know the difference.
I wonder if it's measuring the Levenshtein distance.

 

The shortcuts for code folding have changed!

the Ctrl + K → Ctrl + / shortcut,
which folds only block comments I thought it might be quite useful, but what do you think?

 

Diff of image files managed by Git

This is also a bit mundane
, but I think it's common to manage images with Git, and being able to compare them side-by-side is a great feature.

Since this is all there is to it, I was hesitant to include it, but the image comparing the orange VSCode icon with the new blue VSCode icon was..

 

summary

Version 1.19 also includes many updates focused on performance improvements, such as the ability to enable/disable extensions on a workspace-by-workspace basis

I think the performance has improved significantly for workspaces with a large number of files and VSCode with many extensions registered, but sadly in my environment it didn't feel any faster.
This isn't because the improvements were in vain, but because my environment is such a light user.

Depending on the large-scale development or development language, I sometimes find myself resorting to Eclipse, so in 2018 I hope to be able to write code using only VSCode

 
That's it.