tailwindcss-intellisense spawns ripgrep process that chews CPU on a project without Tailwindcss #986
Comments
|
Looks like Dev Container's had a similar issue that they fixed / worked around: microsoft/vscode-remote-release#9738 It's not open source (that I can see) so I don't know exactly what they did to fix it but one of the comments gave me potential ideas to go on. I'll see what I can come up with. Thanks for reporting this! |
|
Okay so a couple of questions:
You're on an NVMe SSD so I doubt drive speed is not even remotely in play here. I wonder if Docker is doing something weird with those directories that causes directory listing and/or other file operations to slow down. |
|
I think I've found something similar in my project. It's a Python data project that as part of normal operation will install tens or hundreds of node projects. There's no tailwind install or config in the project root though, is there a sensible way I can disable it? I have the plugin installed for other projects I work on 😃 |
|
i think i have a similar problem. I noticed when my laptop suddenly started crashing. When i looked into my processes: |
|
same here |
|
Same issue |
|
I have the same issue happening. On the latest version (0.12.15) when enabled, it spawns tens of If I can provide some more info to help troubleshoot the issue, please let me know how and I'll happily provide it. |
|
Same. After installing this extension and opening a (large) codebase that doesn't use Tailwind, it spawns many of the same process: The number of processes keeps growing and growing until eventually my computer becomes very unhappy. Using version |
|
So we don't spawn these processes directly. They are spawned by VSCode — likely due to registering watch patterns. But I can't think of a reason these would spawn a bunch or use 100% CPU. @BFranse @decafdennis Would it be possible to provide access to a project that reproduces the issue (even if privately via GitHub?) |
Sorry, I can't... if you have any quick pointers on how to debug, I'd be happy to try. The extension works fine in the repo where I need it, though, so for now I'm happy to just enable it on a workspace-by-workspace basis. |
Sorry, I can't. Like @decafdennis I'm happy to try and provide any info you'd need. Edit: I was writing up all my details and wanted to attach a video, and it doesn't seem to cause issues anymore now. |
|
By any chance does using the I've also seen some reports in other extensions that the ripgrep process can have problems when symlinks are involved. Could that be the case here? |
|
Note: This investigation was based on the current I just spent several hours tracking things through VSCode's source. A number of things result in a ripgrep process being spawned like searching for files in the sidebar, clicking file URLs in terminal (if my reading was correct), searching through notebooks, etc… However, the only extension APIs that eventually invoke ripgrep are:
Our extension ONLY uses After the extension starts we:
Notably, file watchers DO NOT invoke ripgrep. These are eventually handled by either Parcel Watcher or Node's built-in file system watcher. So, as far as I can tell, the only invocation of ripgrep caused by our extension is our up to two calls to The two calls we make are for these two globs
Microsoft has a wiki note specifically about excessive ripgrep CPU usage. This article seems to call out a few big causes:
SolutionIt looks like there's not a whole lot we can do solve the problem. However, we do have the ability to cancel the search if it takes too long. While I was never able to reproduce ripgrep running "forever" I have reproduced it running for several seconds on the 1000 pkg / 200k file project I mentioned above. I've opened a PR to cancel searches after ~15s in #1242. I'm hoping this will actually terminate any "stuck" processes but testing this scenario doesn't seem to be possible for me. WorkaroundsAside from the PR there are some workarounds that could potentially speed up or entirely eliminate the searches for some people: Disable following symlinks while searchingThis advice is given in the above linked wiki note. Disabling this appears to speed up ripgrep significantly in some of my tests. Add the following to your settings. This is especially important if you use PNPM and are seeing this in projects: Use the
|
Fixes #986 (hopefully) There's a lot of detail about the problem in the linked issue and my response at the bottom. But briefly: - Searches can take way too long; even spinning "forever" for some people - This occurs more often if following symlinks is enabled in VSCode - We can cancel in-flight searches This PR starts the searches and cancels them after ~15s. If the extension hasn't found anything within 15s then it's likely it'll take ~15s any time you open that project and that would've been an absolutely horrible dev experience that we probably would've been notified about. It seems reasonable to set a time limit on the search do determine if we need to start a language server
|
I'm planning on pushing out a release either tomorrow or Thursday with the fix from #1242 👍 |
|
hey folks, I did an extension bisect and still seeing this issue happen today. Whenever I open up a project with the extension enabled (even though the project doesn't use any tailwind at all), it spins up a LOT of ripgrep processes that just spin and spin basically forever. Note that I already have |
|
Hmmm… any chance you could provide the project? After #1242 the ripgrep processes should definitely get terminated after about 15s so they certainly shouldn't stick around Since you have following symlinks turned off already that leads me to believe your project is exhibiting some other behavior that's causing the ripgrep processes to hang which might be a bug in ripgrep itself. |
|
Also, how many ripgrep processes are you seeing? Are you sure you're not seeing listed threads? I know, for example, that htop on linux will list user space threads as separate entries by default. From my investigation VSCode should only end up spawning up to 2 processes per opened workspace from our extension. |
|
I'm looking at Mac's Activity Monitor which was showing like 10-15 processes. Can't share project unfortunately, it's happening on a closed-source one. It might be another behavior, like you say. Anything I can do to help you troubleshoot this? |
|
found vscode was spawning 900 simultaneous |
|
@joeflateau … 900?! How many workspaces do you have open in a project? We should only ever spawn at most 2. |
|
@niieani Unfortunately without access to a viable reproduction, there's likely nothing else I can do troubleshoot this if you're still seeing the problem. I tracked this even through VSCode itself and it seems like we should definitely only spawn at most 2 processes per workspace. I could only imagine this spawning a lot if you had many separate windows open in VSCode. I've still never had a proper reproduction of this behavior because it seems that any project people see this on is always closed source. |
|
@thecrypticace yeah haha, pretty wild. I ran this script and let it ride for a few minutes and it would grow pretty quickly to 800-900 processes not quite sure the number of workspaces in the project. it's a large yarn monorepo |
|
@joeflateau If you open just one folder and not a What do you see in the extension output Command Palette » "Tailwind CSS: Show Output" when this happens? |
|
Oooh also is the Yarn monorepo using PnP? I wouldn't be surprised if the PnP runtime somehow breaks the extension host (it monkey patches all kinds of Node internals) |
|
@thecrypticace ah right, yes, then it's a single workspace in that sense. it's a yarn v1 project so shouldn't have PnP. logs are: Also notable that this particular project does not use tailwindcss |
|
Oh… that check should definitely not be repeating. That's useful info. Gonna look into that. It's interesting to me that apparently vscode does not (or can't) kill the ripgrep process when the timeout is hit and the request is cancelled. |
|
Speculative fix for that maybe here #1287 I'm really annoyed I didn't notice this earlier. I'm betting you have an absolute crap ton of tabs open in VSCode? I think this might be the cause because we're initiating the file search once a document is opened — though we should only initiate it once but looks like we're doing so N times. 😬 |
|
@thecrypticace I have 5 files open right now :D |
|
oh… well then there's definitely something else going on too then 🤔 |
|
Oh right |
|
@thecrypticace i was going to suggest that may be the case. Probably some other extension scanning files |
|
Gonna re-open this as a reminder to get that other PR finalized and merged |
…1287) We run a file search on a per-workspace basis but we wait until a file has been opened. However, there are two big problems here: - A file being "opened" does **not** mean it is visible. Just that an extension has, effectively, taken an interest in it, can read its contents, etc. This happens for things like tsconfig files, some files inside a `.git` folder, etc… - We're running the search any time we see an opened document. What should happen is that we run the search when a document is opened _and visible_, the language server has not started, and we need to checking a workspace folder that has not been searched yet. This code here needs to be restructured to ensure that these searches only run when they are needed. If the searches don't return anything or time out then they should not be run again. Notifications from file watching should take care of the rest in case the initial search turned up nothing and the user adds a file that should cause the server to start. Fixes #986 (for real maybe this time??)
|
Okay, planning on getting a release out with a second fix for this. Should be either today or tomorrow. |
|
Edit: See correction below. I believe I ran into this problem when working on a project in WSL. Installing Disabling and uninstalling the extension in both WSL and local client does not stop the process. Full windows restart after doing so was required. |
interesting... maybe it follows a symlink and escapes the project dir |
Correction. Accessing closed projects appears to be VSCode acting alone. Rerunning the WSL project after uninstalling the extension and rebooting showed VSCode is the only culprit on that count. Really weird to see my Once the tailwind extension update is out I will give it a go and see if it resolves the remaining CPU usage issue when inside WSL. |
|
Looks like with v0.14.14 it is still running at ~100% on a single thread inside WSL. Below are screenshots from For reference I have an Intel Core Ultra 7 155H, 3800Mhz, 16 Cores, 22 logical procesors. WSL has access to all processors and 16GB, half, the available ram. 
|
For reference here is 
|
|
@Soundvessel This is probably this issue: #1303 In this case ripgrep isn't the thing consuming CPU. There's a bug in a library we changed over to. Hoping to figure out a workaround for it tomorrow. |
What version of VS Code are you using?
What version of Tailwind CSS IntelliSense are you using?
v0.10.5
What version of Tailwind CSS are you using?
No tailwind in my current project.
What package manager are you using?
n/a
What operating system are you using?
Fedora Linux 40 with
/homeas a BTRFS subvolume on a local NVMe drive.Tailwind config
N/A
VS Code settings
{ "python.defaultInterpreterPath": "/bin/python", "workbench.startupEditor": "none", "application.shellEnvironmentResolutionTimeout": 30, "editor.minimap.enabled": false, "workbench.colorTheme": "Monokai Pro (Filter Machine)", "workbench.iconTheme": "Monokai Pro (Filter Machine) Icons", "editor.mouseWheelZoom": true, "files.trimTrailingWhitespace": true, "editor.renderWhitespace": "all", "[python]": { "editor.detectIndentation" : false, "editor.insertSpaces": true, "editor.tabSize": 4, "editor.formatOnType": true, "editor.codeActionsOnSave": { "source.fixAll": "explicit", "source.organizeImports": "explicit" }, "editor.defaultFormatter": "ms-python.black-formatter" }, "editor.multiCursorModifier": "ctrlCmd", "redhat.telemetry.enabled": false, "editor.fontSize": 20, "editor.tabSize": 2, "files.insertFinalNewline": true, "cSpell.ignoreWords": [ "vofhoa" ], "files.associations": { "*.nomad": "hcl", "*.toml": "toml", "*.ign": "json", "*.jinja": "jinja", "*.j2": "jinja-yaml", "*.bu": "jinja-yaml" }, "vs-kubernetes": { "vs-kubernetes.minikube-show-information-expiration": "2024-01-16T23:50:49.632Z", "vs-kubernetes.crd-code-completion": "disabled" }, "editor.acceptSuggestionOnEnter": "on", "editor.quickSuggestionsDelay": 50, "editor.find.autoFindInSelection": "never", "editor.autoIndent": "full", "window.closeWhenEmpty": true, "editor.emptySelectionClipboard": true, "files.encoding": "utf8", "editor.detectIndentation": true, "editor.dragAndDrop": true, "go.toolsManagement.autoUpdate": true, "editor.codeActionsOnSave": {}, "[hcl]": {}, "emeraldwalk.runonsave": { "commands": [ { "match": "\\.nomad", "cmd": "nomad fmt ${file}" } ] }, "python.terminal.activateEnvInCurrentTerminal": true, "python.analysis.fixAll": [], "terminal.integrated.sendKeybindingsToShell": true, "[jinja-html]": {}, "editor.rulers": [ 119 ], "yaml.schemas": { "https://squidfunk.github.io/mkdocs-material/schema.json": "mkdocs.yml" }, "yaml.customTags": [ "!ENV scalar", "!ENV sequence", "tag:yaml.org,2002:python/name:material.extensions.emoji.to_svg", "tag:yaml.org,2002:python/name:material.extensions.emoji.twemoji", "tag:yaml.org,2002:python/name:pymdownx.superfences.fence_code_format" ], "editor.defaultFormatter": "ms-python.black-formatter", "inference.model": "custom", "editor.formatOnSave": true, "git.openRepositoryInParentFolders": "never", "mypy.targets": [ "app" ], "docker.dockerPath": "podman", "docker.environment": { "DOCKER_HOST": "unix:///run/user/1000/podman/podman.sock" }, "settingsSync.ignoredSettings": [ "-docker.environment", "-docker.dockerPath" ], "docker.networks.groupBy": "NetworkName", "notebook.defaultFormatter": "ms-python.black-formatter", "python.REPL.sendToNativeREPL": true, "explorer.fileNesting.patterns": { "*.ts": "${capture}.js", "*.js": "${capture}.js.map, ${capture}.min.js, ${capture}.d.ts", "*.jsx": "${capture}.js", "*.tsx": "${capture}.ts", "tsconfig.json": "tsconfig.*.json", "package.json": "package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb", "*.sqlite": "${capture}.${extname}-*", "*.db": "${capture}.${extname}-*", "*.sqlite3": "${capture}.${extname}-*", "*.db3": "${capture}.${extname}-*", "*.sdb": "${capture}.${extname}-*", "*.s3db": "${capture}.${extname}-*" } }Describe your issue
If I enable the tailwindcss-intellisense extension and launch VS Code in a project directory that does not have any TailwindCSS code (AFAIK) the extension spawns a
rgprocess that uses 1000%+ CPU.This project is an private one that I use to manage container apps on my workstation. It has a data directory that container applications like home assistant, paperless, gitea etc use as volume mounts.
Some of these projects do have
.tsand.jsfiles in this directory so maybe it is choking on watching all of those files? Maybe the extension should check for a tailwind config and only spawn thergprocess if it knows that TailwindCSS is being used in the project root?The text was updated successfully, but these errors were encountered: