-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU usage and unresponsive autocomplete #327
Comments
I am experiencing the exact same issue, and narrowed it down to this extension. Uninstalling and reinstalling does not fix the issue for me. |
Turns out that my solution worked for me, but probably for a coincidence. I edited the I noticed that the autocomplete takes a while after a change in the configuration, so it must be due to an internal rebuild. I'm not using the JIT so the produced CSS is 3MB and this might add to the time required to recalculate the intellisense. I have also a watcher active to rebuild the site I'm working on. I'm not sure if this also plays a role. To further narrow down the problem I decided to install one of the older version, the v0.6.0, from VSIX to check if the problem was introduced somehow in a patch. I'm currently monitoring the cpu and ram usage while working on the website. Let's see if I'm able to get some more insights. |
I actually reverted back to version Tip (not sure if this is an insiders feature only) but you can install different versions of extensions without installing from the VSIX: |
I am pretty sure this is a duplicate of #316, but maybe not. Either way, please can you update to |
Installing now the new release. I'm not entirely sure it was the JIT since I didn't activate it on that project and I didn't see duplicates in the intellisense. Will comment again after some hours of use. Thanks @bradlc |
I have tried to recreate the original problem, but I was not fully able. I saw only some lags when saving rapidly the Tailwind config file while having Laravel Mix in watch mode with browsersync active. At this point I think it can be as you said, an effect of #316 |
I'm installing |
I don't think |
@alexweininger @avvertix If you're not using |
Sure, upgrading now, I didn't realize there was a new patch version |
I published it today to change the server filename from |
I have more insights. I tried in different conditions. Since I'm building a static website I decided to try with
The strange effect is that when editing with no webserver active or watch everything seems to runs smoothly and fast as expected, but when I rebuild the website the cpu spikes again for some time. Considering that the static site builds the html in a folder within the opened folder in VSCode I'm thinking that there should be a connection. I'm also trying on a different computer to see if there is something else to consider. |
I don't suppose there's any way you can share your project, even just privately with me? |
I think I can let you access a stripped version by excluding some information that should not be visible. I'll sort it out and let you know. |
I got the ok, so I invited you to a private repo with a stripped version. Let me know if you prefer to switch to email communication |
@bradlc I am experiencing the same issue on a private Next.js codebase (30k lines).
|
Had to revert to 0.5.10 too.. it was getting worse and worse.. my fans were spinning like jet engines and my system was becoming unresponsive.. and all this while editing a Laravel project with php files and no Tailwind classes anywhere |
I have the exact same issue, I thought it is concern with VSCode v 1.56.2 because I noticed it after upgrading vscode, but then I found out the extension is consuming really high cpu and memory and fans always very loud. I have version 0.6.6 |
Reverting back to 0.5.10 seems to have fixed it for me. Before it was forcing my ram to 90% usage and 100% cpu. |
Also experiencing this on 0.6.6 on a smaller Ruby/Rails codebase. If it means anything I am also using Onivim2, so not VSCode. |
Hey all. I am keen to get to the bottom of this, so I have just published a new version of the extension (
This is where my knowledge is limited but from here you can record a CPU profile ( |
Sure. I just recorded a cpu profile for you to look at. Hopefully it helps you. While i used the profiler it spiked at 70% cpu in the vscode process explorer |
Thank you @rexdesigndk! 🙏 So my working theory based on that is that it's something to do with the file watcher (chokidar). I am actually working on removing the file watcher completely but want to test a few things first to see if we can find the root cause, because some editors (not VS Code) will still need to use it. I have created a couple of special builds with specific changes. I have still been unable to reproduce the issue myself so I would appreciate it if anyone could try out both of these builds and let me know if the issue persists:
To install:
|
I installed both versions and used the chrome profiler while i was developing on a project. Just looking at the process explorer It seemed to me that removing chokidar helped a lot. But downgrading it, didn't seem to help at all. |
Amazing, thank you again @rexdesigndk ❤️ The I have one more build that I'm curious about if you wouldn't mind testing this one: vscode-tailwindcss-0.6.8-cwd.zip. This one has a minor change to the chokidar options that may or may not do anything 😅 Really appreciate you taking to time to help debug this! |
Sure no problem. Here you go |
I'm late, but here my profiles The content is the following
@bradlc I'm thinking the same as you, at least in my case having the watcher also at the project level to rebuild the static website as I work on it seems to suggest that the intellisense plugin receives a lot of notifications from chokidar (I believe it receives also notifications about git changes, as the project is under version control). I'm not sure if this causes more internal rebuild, as from the method names in the profile is not clear. I'm not sure and I don't know if could be a possibility, but considering that in my case also the RAM was filling, maybe there is a chance you are recreating an instance of something that references the file system watcher. This is just a guess and the memory snapshot is not so readable and also difficult to obtain when the problem arises, so I don't have proof |
@avvertix Yeah the memory thing is still a mystery to me. Thanks for the profiles, they are super interesting! So bizarre that the issue seems to only present itself when you run a build, or have your own watcher running. Are you using Docker by the way? Also a couple follow-up questions for you @rexdesigndk: are you using Docker or something else where your project is running inside a virtual machine? Also did you have a watcher running when you did your profiles? |
I suspect this may be related to an extension that we all use. Off the top of my head I use https://github.com/Zignd/HTML-CSS-Class-Completion and https://github.com/bmewburn/vscode-intelephense which are both watcher-type extensions |
Yes i run my projects in a docker container and i have npm watch running. |
No, I have PHP 7.4 and Node 14 installed directly on my computer. I use Yarn as package manager on those projects, version 1.22.
I'll try to disable all the extensions except Tailwind IntelliSense to get a better idea if those can have an impact. There are the ones I currently have active
I'm not entirely sure how others could play a role, but I'll try to disable all of them for a test. @bradlc Btw I discovered a pretty interesting option, in the process explorer within VS Code you can debug the tailwindServer by right click and choose Debug. VS Code then will connect the debugger to it. Unfortunately the code is minified and unreadable, so I'm not sure where to put a breakpoint. |
I don't use any of these :) |
@avvertix How was your memory usage looking when using the |
From what I observed it was acceptable and improved in comparison with the abnormal consumption in the other case. Let me do another test to confirm that. |
@avvertix Thanks! This build has some logging when directories are being read by chokidar: vscode-tailwindcss-0.6.8-read-log.zip – it's also unminified If you could, install this build and take a look in the server output ( |
awesome @bradlc I'll try it immediately |
@bradlc here it is the output file with the debug info
yes, and it prints various The execution was:
I think the listed paths will be self-explanatory, but the line 8493 states when the plugin finished the initialization with
Thanks, I saw where you placed the debug log and the I also took a bit of time to profile the RAM usage, but I was able only to get information up to a certain point of the execution as heap memory dump is unreliable when the problem appears. Basically it starts with around 64 MB and then after the first save was already at 140 MB. I guess this is connected to the number of files in my folder that the watcher notifies each times a save operation happens or a change in the folder structure. |
Thanks @avvertix! I really have no idea what's causing this haha. My latest approach is to just replace chokidar and hope the issue goes away 😅 vscode-tailwindcss-0.6.8-parcel.zip – if anyone is able to try this build and run a CPU profile for a bit that would be amazing. |
Thanks @bradlc ! I installed right now the build. I'll run the profiler and let you know. |
Here some profiles @bradlc
At a glace I would tentatively say that the profiles looks more natural than the previous ones. Also the memory consumption (seen from the memory profiler) seems stable spanning from 35 MB (before the tests) to 80 MB after the end of each test. |
Ok yeah that is looking way better! 🙌 I have one last build if you wouldn't mind trying it out? This one still uses Following any feedback from this build I am planning to get a release out this week that will hopefully address this issue 👍 |
I will for sure try it out! |
A bit later than expected, but here it is It is a longer single session doing the usual edit to the file alone, do a build of the project, call the autocomplete and then use the watcher. I think this build is in the middle between |
Thank you @avvertix and @rexdesigndk for your help debugging this ❤️ The latest release ( |
You're welcome @bradlc Upgrading to |
How's it looking @avvertix? 👀 |
So far everything is good on my side. I would say the issue is resolved and can be closed from my point of view |
Same for me. It's been running flawless 👌 |
Brilliant! I'll close this then, but feel free to open a new issue in the future if you run into anything else 👍 |
For anyone else that might still occur this: I had the whole user folder |
Hi, thanks for the great extension that saved me a lot of time. With the latest update (0.6.3) I was experiencing some hiccups. Although I'm not sure this is a bug or a problem of the extension per se I'm opening the issue in case someone is searching the same problem and trying to find a solution (or at least the solution that worked for me).
Description
I was migrating a static site project that used Tailwind 1.9 to Tailwind 2.1 and after updating all Javascript dependencies to use Laravel Mix 6 and Tailwind 2.1 the autocomplete was very slow and unresponsive. I was experiencing this in Blade files, but I think it was not really connected to the type of file.
From the task manager the effect of this was a process, pertaining to VSCode, using more than 7GB of RAM and about 60% of the CPU continuously. Terminating that process would terminate and restart the Tailwind CSS IntelliSense extension. After that the extension works for some minutes before again occupy all the resources
I'm referencing here the loaded versions and files as reported in the output of the extension. The tailwind config file is almost empty.
Actions done
After some time I decided to disable the extension to confirm that the problem was caused by the Tailwind IntelliSense and in fact the CPU and RAM usage was back to an acceptable level. Re-enabling the extension unfortunately recreate the same problem.
In order to resolve it I uninstalled the extension and installed it again. Once reinstalled the autocomplete was again very quick and the system resources were back to a normal level.
I'm not sure what was causing the problem and I didn't investigate it deeply.
The text was updated successfully, but these errors were encountered: