High CPU usage with GraphQL.vscode-graphql extension

[borekb]

Issue Type: Performance Issue

With this extension disabled and some TypeScript files open in my editor, I was seeing an issue with the "Electron" process consuming ~300% CPU on my Mac, similar to e.g. https://github.com/microsoft/vscode/issues/142828.

Extension version: 0.4.6 VS Code version: Code 1.67.2 (c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5, 2022-05-17T18:20:04.972Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 Max (10 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 3, 4
Memory (System)	32.00GB (4.53GB free)
Process Argv	--crash-reporter-id 62e8a5cc-5388-43c6-9d85-144bc05db333
Screen Reader	no
VM	0%

Process Info

CPU %	Mem MB	   PID	Process
   22	   262	 98686	code main
    2	    98	 98689	   gpu-process
    0	    33	 98691	   utility-network-service
    4	   623	 98693	   window ([sofa] packages/graphql/schema/auth/index.ts)
    0	   295	 98884	   shared-process
    0	    66	 98892	     ptyHost
    0	     0	 99082	       /opt/homebrew/bin/zsh -l
    0	     0	 99105	         /opt/homebrew/bin/zsh -l

Workspace Info

|  Window ([sofa] packages/graphql/schema/auth/index.ts)
|    Folder (sofa): 10157 files
|      File types: zip(7457) tsx(560) ts(528) json(253) js(239) yml(147)
|                  pack(94) md(85) svg(32) attrs(20)
|      Conf files: package.json(28) tsconfig.json(19) github-actions(5)
|                  dockerfile(3) launch.json(1) settings.json(1)
|                  tasks.json(1)
|      Launch Configs: node;

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebug:30492333
vscaat:30438848
vsclangdc:30486549

[macsj200]

I've been getting an error message saying the language server crashed recently.

[acao]

thats another issue related to a change in vscode in a recent release. there is a ticket open for that now

[acao]

@borekb is this still an issue?

[borekb]

@acao Just tried and the extension is still causing high CPU of the "Electron" process:

This only happens when I enable the GraphQL extension.

[acao]

Is this in a project with graphql config? How many files do you estimate you have?

I have some projects I will try out this weekend to see what can be done.

[borekb]

Yes, we've got .graphqlrc.yml that looks like this:

projects:
  shops-manager-tests:
    schema:
      - ./sp/apps/shops-manager/src/schema.graphql
      - scalar Upload
    documents: ./sp/apps/shops-manager/tests/**/*.ts
  shops-manager-client:
    schema:
      - ./sp/apps/shops-manager/src/schema.graphql
      - scalar Upload
    documents: ./sp/libs/shops-manager-client/**/*.ts
  preview-deployments-autoscaler:
    schema:
      - ./sp/apps/shops-manager/src/schema.graphql
      - scalar Upload
    documents: ./sp/apps/preview-deployments-autoscaler/lua/queries/*.gql
  portal:
    schema:
      - ./sp/apps/shops-manager/src/schema.graphql
      - scalar Upload
    documents: ./sp/apps/portal/**/*.{ts,tsx}
  sofa-fenix:
    schema: ./packages/sofa-fenix/graphql-api/schema.graphql
    documents: ./packages/sofa-fenix/gqls/*.ts

All the globs might resolve to something like a ~100 files. It's also possible that our configuration is not entirely correct – we've seen issues with it but didn't have time to review it yet.

[acao]

I know exactly the issue and it's a relatively easy fix given the size of the issue, this must be so annoying. I introduced quite a perf regression ~ 2 years back by having the LSP server re-load all projects when a file is saved, rather than just the project for that file. I haven't been manually testing with complex enough multi-project configs anymore so I hadn't noticed this! this will get a bit more complex when we finally add support for multi-root workspaces

i think this entire approach is faulty - it originated with the issue of changes to SDL files in a project not being reflected right away in queries/other SDL files, but we should just be incrementally updating the cache on each workspace change. there is a way to use the client LSP watcher to notify of all workspace changes, instead of just the changes issued from vscode (codegen, dependencies, etc) and rebuild the cache more efficiently overall

even if we were to switch to the relay LSP compiler, we would need to figure out this problem of graphql-config, and also how to cache multiple projects in each workspace in multi-root contexts as well. in the relay compiler lsp server, I think they would need to each be environments named ${workspacePath}-${projectName} or some such

[acao]

@borekb we're finally working on some optimizations!

https://github.com/graphql/graphiql/pull/2594

[borekb]

@acao awesome to hear!