v0.3.0-alpha-1 makes VSCode take 100% CPU

[rik]

I've installed the alpha to get the goodness from #58.

After installing it, I'm getting 100% CPU all the time. I realise this might not be very actionable as a bug report so I am happy to spend time getting you the logs that you need to investigate.

[bradlc]

Hey @rik. Thanks for trying it out. When you say "all the time," is this happening even when you aren't interacting with the editor?

Also please can you confirm that this is not happening after disabling the extension, and that it is happening with all other extensions disabled? There's a "Disable All Installed Extensions" command you can run from the command palette that might help with that.

Also what OS are you using, and which version of VS Code?

[rik]

Without interacting: CPU spike
After disabling only VSCode Tailwind: CPU idle
Only VSCode Tailwind: CPU spike

VSCode details:

Version: 1.44.2
Commit: ff915844119ce9485abfe8aa9076ec76b5300ddd
Date: 2020-04-16T17:07:18.473Z (2 wks ago)
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.4.0

[jeffchown]

I can confirm (after toggling each extension in VSCode) that this is happening for me too - even with no file tabs open (just an active vscode workspace).

Reverting to v0.2.0 fixes the problem.

My output from code --status - with v0.3.0-alpha-1 enabled:

Version:          Code 1.44.2 (ff915844119ce9485abfe8aa9076ec76b5300ddd, 2020-04-16T17:07:18.473Z)
OS Version:       Darwin x64 18.7.0
CPUs:             Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz (4 x 1700)
Memory (System):  8.00GB (0.03GB free)
Load (avg):       4, 4, 6
VM:               0%
Screen Reader:    no
Process Argv:     
GPU Status:       2d_canvas:                     enabled
                  flash_3d:                      enabled
                  flash_stage3d:                 enabled
                  flash_stage3d_baseline:        enabled
                  gpu_compositing:               enabled
                  metal:                         disabled_off
                  multiple_raster_threads:       enabled_on
                  oop_rasterization:             disabled_off
                  protected_video_decode:        unavailable_off
                  rasterization:                 enabled
                  skia_renderer:                 disabled_off_ok
                  video_decode:                  enabled
                  viz_display_compositor:        enabled_on
                  viz_hit_test_surface_layer:    disabled_off_ok
                  webgl:                         enabled
                  webgl2:                        enabled

CPU %	Mem MB	   PID	Process
    0	    82	  3871	code main
    0	    49	  3872	   gpu-process
    0	    25	  3874	   utility
    0	   106	  4270	   shared-process
    0	     0	  7057	     /bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=
    0	   319	  6798	   window (rectracker3 (Workspace))
    0	   115	  6799	     extensionHost
    0	   139	  6806	       electron_node vueServerMain.js 
   38	   115	  6865	       electron_node index.js 
    0	    49	  6800	     watcherService
    0	    41	  6801	     searchService

Workspace Stats: 
|  Window (rectracker3 (Workspace))
|    Folder (rectracker3): 11922 files
|      File types: php(7039) txt(695) json(592) phpt(284) md(283) vue(161)
|                  css(145) xml(140) yml(71) js(67)
|      Conf files: package.json(3) makefile(3) settings.json(1)
|                  tsconfig.json(1) webpack.config.js(1)

Aside from the high CPU, was loving the update!

[bradlc]

Thank you both for providing that info, it's really helpful!

I reckon I might have tracked the issue down. I was seeing that the language service was running at ~10% CPU usage on my machine, even when the editor was idle (and in a very small example project), when really it should be ~0%.

I made a change to the file watcher the other day which added **/{tailwind,tailwind.config,tailwind-config,.tailwindrc}.js to the list of watched files, in addition to the dependencies of the user's config file. The reason for this was basically to be able to catch instances where the user moves an existing config file to a new folder.

The reason I think this is causing high CPU usage is because the watcher is potentially watching very large directory structures like node_modules. When adding node_modules to the list of the watcher's ignored paths, or removing the glob, the CPU was back down to 0%.

So the quick fix for most users (I imagine) is to just add node_modules to the ignored paths, but in hindsight I think there's a better way to handle the "config moved" situation, so I am going to look at a way to do that without having to have any globs in the watch list (specific files only!)

If you could bear with me for a day or two I will add this to the list for v0.3.0-alpha.2, and I'm hoping to get that out this weekend. Thanks again!

[jeffchown]

You're welcome, @bradlc - sounds like you've tracked it down 👍
Looking forward to using 0.3.0-alpha-2 once it's good to go - Thanks for the great work!

[bradlc]

v0.3.0-alpha.2 is out with some changes that will hopefully fix this issue 🤞

I actually found another big issue with the file watching, which was that the fsevents binary was going missing in the build process. Fixing this should have made file watching much more efficient on macOS 🙌

The project I was getting ~10% CPU usage on was back down to 0% just by fixing the fsevents issue, but I have also changed which files get watched as I mentioned the other day.

If you could try out the new release and let me know if it improves things that would be great, thanks!

[jeffchown]

Morning @bradlc - sounds great. Looking forward to giving alpha.2 a try. I've installed it and will keep an eye on its CPU usage over the course the day. Thanks for the quick turnaround and thorough debug!

[jeffchown]

Hey @bradlc - I've been using VSCode all morning (with alpha.2 installed) and my CPU % has hovered nicely between 0 - 3%. Looking good. Thanks!

[rik]

I can confirm this is gone for me too. Thanks for the quick turnaround!

[bradlc]

Thanks @rik @jeffchown 🙌

I'll close this, but please feel free to open a new issue if you see this again.