Severe performance degradation opening large folders in latest release

[starkat99]

• VSCode Version: 1.37.1
• OS Version: Windows 7

I regularly have Code open to a workspace with a large number of files in a single folder ( >20k files). I've never really had a problem with that until the latest release of 1.37.1, where I experience severe lagginess in every element of Code UI, especially text response in editor windows and terminal. This occurs even when Explorer sidebar is not visible. CPU usage shows Code using a large percentage of CPU. Previous version 1.37 seemed ok (but not great) for the day or two I had it, and I definitely know 1.36 builds worked just fine for this case. This issue occurs with extensions disabled (it's pretty much impossible to run with extensions at all in this state).

Steps to Reproduce:

1. Open a folder workspace with a large amount of files. Explorer sidebar does not need to be open.
2. Observe laggy UI performance, laggy typing in text windows, especially a terminal window. The performance will sometimes improve briefly, before degrading again after performing any action.

Does this issue occur when all extensions are disabled?: Yes

[gjsjohnmurray]

/needsMoreInfo - please review https://github.com/Microsoft/vscode/wiki/Performance-Issues and post the additional info it suggests gathering.

[vscodebot]

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.

Happy Coding!

[starkat99]

Here's the performance issue reporter data, and attaching the both the Javscript profiler data and Performance profiler data of me typing into a terminal while a folder with 20k files is open (where it has >2s typing lag)
CPU-20190820T142627.cpuprofile.txt
Profile-20190820T143149.json.txt

CPUs | Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (12 x 3491)
-- | --
GPU Status | 2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled
Load (avg) | undefined
Memory (System) | 63.91GB (55.26GB free)
Process Argv | --disable-extensions --verbose
Screen Reader | no
VM | 0%

CPU %	Mem MB	   PID	Process
    0	    95	  6416	code main
    0	    64	  3792	   window (Issue Reporter)
    0	    19	  3816	   utility
   23	    69	  5188	   shared-process
    0	   107	  7392	   gpu-process
    0	    11	  9876	   electron-crash-reporter
    0	   421	 10792	   window (Welcome - _materials - Visual Studio Code [Administrator])
    0	     5	 11020	     winpty-process
    0	     4	 11048	       C:\WINDOWS\system32\cmd.exe
    0	    13	 11056	     watcherService 
    0	    68	 11196	     extensionHost

|  Window (Welcome - _materials - Visual Studio Code [Administrator])
|    Folder (_materials): more than 21242 files
|      File types: xml(21242)
|      Conf files:

Extensions are disabled

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[starkat99]

Same thing on Insider's build, here's a new set of performance captures using insiders

Profile-20190821T132035.json.txt
status.txt
CPU-20190821T132143.cpuprofile.txt

[bpasero]

@RMacfarlane moving to you as this looks like shared process is spiking, probably the workspace statting? Is there a way to turn that off?

[RMacfarlane]

Yes, this is likely due to the workspace stats call. I made a change yesterday that should improve perf somewhat, @starkat99 can you let me know if you see any difference with today's insiders?

On tomorrow's insiders, changing the telemetry.enableTelemetry setting to false should avoid the workspace stat computation being made at all

[gjsjohnmurray]

For another tip to reduce stat load see #78710. I submitted a PR for that issue but it hasn't yet been accepted.

[starkat99]

Sorry for the delay. I tried the latest insiders again, nothing's changed. Still getting severe performance issues. Attaching new profiling results
Profile-20190826T134134.json.txt
CPU-20190826T134253.cpuprofile.txt

[RMacfarlane]

@starkat99 Thanks for testing it. Did changing the telemetry.enableTelemetry setting in that version have any impact?

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[starkat99]

I tried this again in today's Insiders build. The issue has mostly gone away, just not completely. Most of the UI seems to be functioning normally now (with or without telemetry enabled, it makes no difference) with the exception of the terminal. As soon as a terminal receives focus (or a new terminal is opened, unhidden, etc.) the severe UI lagginess returns to the entire UI. But once I change focus away from terminal or close it and give it a couple seconds for the lag to resolve, the rest of the UI returns to regular performance. So, as long as I avoid using a terminal everything is usable again with a large workspace folder.

[RMacfarlane]

Thanks @starkat99!

I'm able to reproduce this issue, I created a folder with 30k text files in it at the top level. This doesn't seem to be related to the workspace stats call, since it also happens when telemetry is off. When the terminal has focus, there are repeated calls to fs.readdir that are taking more than a second to return

[Tyriar]

This this new setting in insiders:

"terminal.integrated.enableFileLinks": false