-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Description
Issue Type: Performance Issue
For Kibana, we have a TypeScript setup with nested tsconfig.json
files. Over the course of the last few months, I and others have started seeing serious latency (10s+) when resolving type information (either via suggestions or code navigation). We've also tried the same setup in Webstorm, and after some initial delay due to indexing, feedback from TypeScript is almost instant in WS.
Our setup (where ./
is the root directory of the Kibana repo):
./tsconfig.json
: type checks./src/**/*
./x-pack/tsconfig.json
: extends the roottsconfig.json
and type checks./x-pack/**/*
- We use yarn workspaces, so npm modules can be resolved from both
./node_modules
and./x-pack/node_modules
The latency issues I have been experiencing are mostly when I'm working on a file that belongs to the x-pack
project, and I want to resolve type information for an npm module. "Local" files are pretty fast to respond with type information (sub-second), but for npm modules, feedback consistently takes around 10 seconds. I've inspected the logs, and seemingly the delay happens because every time type information for an npm module is requested, the TypeScript service starts the root project, and closes it again after the tab is closed. I've taken the following steps to reproduce the issue:
- Check out elastic/kibana@e14dcb2 (this was the most recent commit when I reproduced the issue)
- Run
yarn kbn:bootstrap
in the root of the directory - Open the Kibana repo in VS Code
- Open
x-pack/legacy/plugins/apm/public/components/shared/ApmHeader/index.tsx
- Observe that it takes around 30s for the TypeScript server to start responding with type information
- Open
x-pack/legacy/plugins/apm/public/components/shared/ApmHeader/DatePicker/index.tsx
via the import statement. - Observe that the file is opened (near-)instantly.
- Open
react
fromDatePicker/index.tsx
, again via the import statement - Observe that the spinner ("Initializing TS/JS language features") starts
- Observe that it takes around 10s for the file (
node_modules/@types/react/index.d.ts
) to open
It's important to note that this doesn't seem to happen once, but every time type information from the inactive project is needed. That means that initially, type info for DatePicker
is instant, but is delayed for react
. After hovering over react
, type information for DatePicker
is suddenly delayed.
I've experimented with splitting up the two projects into smaller ones which seems to resolve the issue (PR here), but maybe it's possible that it could be fixed in VS Code as well. I'm optimistic that this is possible given the fact that Webstorm can display instant feedback.
Logs:
ts-logs.txt
VS Code version: Code 1.39.2 (6ab598523be7a800d7f3eb4d92d7ab9a66069390, 2019-10-15T15:33:00.827Z)
OS version: Darwin x64 18.7.0
System Info
Item | Value |
---|---|
CPUs | Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 x 2900) |
GPU Status | 2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: enabled oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: disabled_off webgl: enabled webgl2: enabled |
Load (avg) | 2, 2, 2 |
Memory (System) | 32.00GB (7.88GB free) |
Process Argv | |
Screen Reader | no |
VM | 0% |
Process Info
CPU % Mem MB PID Process
14 164 47107 code main
5 98 47108 gpu-process
5 98 47498 shared-process
Workspace Info
| Window (index.tsx — kibana-backup)
| Folder (kibana-backup): more than 24161 files
| File types: js(5297) ts(5054) md(949) tsx(887) json(634) scss(579)
| png(435) map(347) asciidoc(302) snap(202)
| Conf files: package.json(98) tsconfig.json(36) webpack.config.js(4)
| grunt.js(2) settings.json(1) gulp.js(1)
| jsconfig.json(1);