Repository navigation
Extension is writing a lot of data to the disk #5362
Description
Activity
Hi @aggserp4. Could you tell us what files are being written to, and their sizes?
It is expected that when a project is created, or its configuration changed, that the extension will (re)build a database of symbols in all headers in all configured paths, in order to provide that information via IntelliSense. That means it will parse all system headers as well as headers from any paths you have configured.
This doesn't appear to be specifically affected by me creating new projects or including more files. It just seems to write more and more data as I write more code. I was working on a couple of files for about an hour just writing some functions and it wrote about 3.6GB to the disk over that period.
I also noticed that the "Updating Intellisense..." symbol was appearing full time while I was editing, and it's still showing up now regardless of which projects I open. That wasn't the case when I opened this issue, though.
As for which files it's writing to, I don't know. I can see which files the process has opened at any given time but I don't know to which ones it's writing. I don't think it's draining any space, if that's of any help.
This sounds like the IntelliSense cache. You can set the size or location via changing the intelliSenseCacheSize and intelliSenseCachePath settings (or set the size to 0 to disable it).
Reacted by Kirill Leyfer and Denis ChurilovSounds about right, I turned it off and it was writing very little data. Turned it back on and it started writing in the same pattern as before.
Still doesn't explain why the "Updating Intellisense..." symbol occasionally shows up and never goes away, but perhaps that's a separate issue.
@aggserp4 The "Updating IntelliSense..." means we're waiting on work from cpptools-srv. So if you see that process using CPU then it's busy doing something (potentially in an infinite loop, although we don't know of any known cases of that currently). If you don't see cpptools-srv then it may have crashed or if you see cpptools using CPU instead, it could be stuck computing recursive includes before it's able to lauch cpptools-srv (removing "**" from your includePath can disable recursive includes).
For the record, I'm having this very issue, but in my case it's not that I'm worried about the amount of data written, it's that writing this very data makes the whole machine totally unusable.
I don't have a laptop with a top-of-the-line NVMe SSD ... and 300MB to 600 MB "drops" every few seconds leads to Linux freezing the whole machine, regularly. I'm happy I finally found why the whole vscode would freeze regularly. I was considering just returning to plain vim.
Colen Garoutte-Carson (@Colengms) I first tried to check which file was being written by stracing cpptools, but nothing was coming up ... and then realized the ipch file is mmaped. So, that's one hypothesis.
Disabling the cache (by setting its size to zero) also solves the problem. Second hint.
Sylvain Joyeux (@doudou) Are you editing a header file when the cache issue becomes a problem? We might be able to disable using the cache when the file that is being edited is the not the source file (#5522). Is the behavior okay in other scenarios?
Are you editing a header file when the cache issue becomes a problem?
I'm not sure. It's so unusable that I just disabled the cache for now. Big deadline coming up, won't have much time looking into it further for now.
Is the behavior okay in other scenarios?
I'm not sure I fully understand the implication of this change.
@aggserp4 could you expand on the reason why you are closing this issue ?
Apologies, I was looking through my issues and closed this one without paying much attention because it had no responses for a while and I had solved my issue by disabling the cache. However it is clear that your problem remains, so I will reopen the issue. This was my mistake.
I should mention that I do not seem to be having the problem you mentioned. I am using a mechanical drive and despite the large amount of data that is being written in a short period of time with the cache enabled, my computer remains responsive.
9 remaining items
auto-pch is another name for the ipch files that get written to disk. If you set C_Cpp.intelliSenseCachePath to something like ${workspaceFolder}/.vscode then it's easier to see when a file is generated or regenerated.
We'll look into possibly changing the default. Not sure yet...
I find that the problem has disappeared maybe due to updates. It only writes a few GiBs data now. What's more, formating speed has also been increased. I have to wait some seconds after Ctrl+S before.
Thank all developers.Kilasue (@kilasuelika) Which update? 1.2.0-insiders? We didn't intentionally change any ipch-related issues, unless you were hitting some crashes that was causing the caching to be repeatedly invalidated.
Formatting speed could be increased due to clang-format changes we did?
I guess it is. Now I see that the version is indeed "1.2.0-insiders". Yesterday when I open the extension manager, some extensions are showing "installing" by themselves and quickly done.
I have been worrying that the CPP extension tools will destroy my hard drive by writing 100G to it every day. intelliSenseCacheSize = 0 trick is so nice. Thanks guys!
had to disable the cpp extension because of high cpu, memory and disk r/w on ubuntu 22.04 from
cpptoolswith the following settings:"C_Cpp.intelliSenseCacheSize": 0, "C_Cpp.workspaceParsingPriority": "low", "C_Cpp.default.browse.limitSymbolsToIncludedHeaders": true, "files.exclude": { "**/.git": true, "**/.svn": true, "**/.hg": true, "**/.deps": true, "**/CVS": true, "**/.DS_Store": true, "/bin": true, "/boot": true, "/cdrom": true, "/dev": true, "/proc": true, "/etc":true },Same here, it shows that almost 5G has been squandered. Seems that these days clangd-like smart tools are in vogue, but they seem to unconditionally indexing system-installed headers regardless of they are being used or not. When working on a project, constantly observing that my computer is voicing pain of disk writing has been a custom. -:) Is there a way to exclude some path from indexing?
how_long_will_it_go (@bach001) Are you able to see what file type is using the disk space? i.e. .ipch or .db? You can try setting C_Cpp.files.exclude for a smaller .db (use a folder glob and not a glob that ends with "**" or you'll need to change the C_Cpp.exclusionPolicy setting). and C_Cpp.intelliSenseCacheSize for fewer .ipch.
Hey I'm experiencing this same issue, and after reading this thread, I got a few questions and suggestions.
- Is the whole intellisense cache invalidated on every modification on any header file ? In that case, wouldn't it be possible (and more relevent) to invalidate only the right chunk of the cache ? (especially for files located in the workspace)
- It seems that the analysis is triggered pretty quick (like cursor changing line or 1-2 secs without keystroke), it could be interesting to wait for the file to be saved.
- For a more trivial solution, maybe just keep it on RAM and write on disk only every
C_Cpp.intellisense.write_on_disk_everyseconds
how_long_will_it_go (@bach001) Are you able to see what file type is using the disk space? i.e. .ipch or .db? You can try setting C_Cpp.files.exclude for a smaller .db (use a folder glob and not a glob that ends with "**" or you'll need to change the C_Cpp.exclusionPolicy setting). and C_Cpp.intelliSenseCacheSize for fewer .ipch.
I didn't see the details. but observed that every tool employing clangd to do the job manifests the same symptom. I guess it should be many many .pch file(for windows vs). I've got a close look when clangd working behind QtCreator.
The essence is the same. So actually this is actually a clangd issue.
OS: Ubuntu 18.04 LTS
VS Code version: 1.44.2
Extension version: 0.27.0
The extension appears to be writing a lot of data to the disk very quickly, for reasons I can't figure out. My projects usually only contain a couple of files that are a few KB in size, yet when I make the slightest edit, save, or do just about anything the extension writes a lot of data to the disk. After about 20 minutes of usage, it has already written over 1 gigabyte of data.
Is this normal behavior or is something wrong? What's causing all those writes?