Slow intellisense with large TS enum (3000+ rows)

[woophi]

Issue Type: Performance Issue

I have a large enum with 3000+ rows. https://pastebin.com/uBXCNxSb
When I try to access some methods or types that have imported this enum - it takes about 20-60 seconds to resolve autocomplete or autoimport.

Do you have any advice or thoughts - how to speed up it?

VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.19042

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2592)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.92GB (8.43GB free)
Process Argv	C:\workflow\vk-friends-app --crash-reporter-id 44b7a940-efb4-4a93-8ff7-b223b05e746f
Screen Reader	no
VM	0%

Process Info

CPU %	Mem MB	   PID	Process
    0	    93	 24988	code main
    0	    87	  1608	   gpu-process
    0	    23	 11480	   crashpad-handler
    0	    38	 20336	   utility
    0	    77	 22056	   window (Issue Reporter)
    0	    85	 22796	   shared-process
    0	   161	 23696	   window (vk-friends-app - Visual Studio Code)
    0	   112	  1592	     extensionHost
    0	    69	  3920	     searchService
    0	    12	  7204	     watcherService 
    0	    11	 23196	       console-window-host (Windows internal process)

Workspace Info

|  Window (vk-friends-app - Visual Studio Code)
|    Folder (vk-friends-app): 4249 files
|      File types: png(3188) ts(440) js(165) map(162) tsx(49) sql(22) json(11)
|                  xml(10) woff(7) woff2(7)
|      Conf files: package.json(3) tsconfig.json(2) settings.json(1);

Extensions (11)

Extension	Author (truncated)	Version
gitlens	eam	11.2.1
prettier-vscode	esb	5.9.2
git-graph	mhu	1.28.0
vscode-docker	ms-	1.9.1
python	ms-	2021.1.502429796
jupyter	ms-	2020.12.414227025
remote-wsl	ms-	0.53.4
vscode-typescript-tslint-plugin	ms-	1.3.3
prisma	Pri	2.16.1
vscode-icons	vsc	11.1.0
material-theme	zhu	3.9.15

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry914:30256638
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt600cf:30251589

[mjbvz]

Works pretty quickly for me with just that enum (a quarter second at most)

Could is there something else in your project that causes this? Do you see this with all extensions disabled too?

[DanielRosenwasser]

I would try out the instructions at https://github.com/microsoft/TypeScript/wiki/Performance#performance-tracing first. This may help pinpoint what work is taking up a lot of time in type-checking.

CCing @amcasey in case he has any questions or can clarify anything

[amcasey]

An enum like that won't be slow on its own - only where it is consumed. @woophi, if you don't already have a sample usage in mind, you can use the tool @DanielRosenwasser linked to identify the part of your code that's taking a long time to check. If you provide a sample usage, we should be able to figure out whether your code and/or the compiler needs to be tweaked.

It would also be helpful to know which version of TypeScript you're using (sorry if it's in the metadata and I missed it) and, as @mjbvz suggested, you'll probably want to try again without extensions (e.g. tslint).

[woophi]

Thanks for help.

I have tried to use performance-tracing tool and found a place where the problem was.
That was a really strange bug or problem, so I ve created a repo https://github.com/woophi/slow-ts

By this commit you can see how I ve resolved it

[amcasey]

Excellent, glad you're unblocked. Thanks so much for the repro!

[amcasey]

It turns out that running a large enum through Immer's Draft is very expensive. I'm still investigating how extracting DataState bypasses that work. How did you figure out what change to make?

[woophi]

@amcasey
I have used performance-tracing tool and found these results

After commenting some part of code in data.ts, I found what was the reason.

This is after fix

[amcasey]

@woophi A few follow-up questions if you don't mind:

1. Did you use anything other than the paths from the tracing tools?
2. How did you know a type alias would help? (As far as I can tell, it takes advantage of a compiler implementation detail, but I'd love to learn that there's a more sophisticated reason that it should help.)

[amcasey]

Got it! Using the type alias makes it obvious to the compiler that the type is not generic and does not participate in type inference (see couldContainTypeVariables in checker.ts). Determining that is trivial for a non-generic type alias, but expensive for this particular mapped type.