Repository navigation
Limit Extension storage usage #185
Description
From @Geeprox on April 13, 2017 9:39
- VSCode Version: 1.11.1
- OS Version: Windows 7
There are so many index.db files that takes a lot of storage space
(for example: \AppData\Roaming\Code\User\workspaceStorage\13d502476c69532f0fce4f9ab9ea9f18\redhat.java\jdt_ws.metadata.plugins\org.eclipse.jdt.core\index.db)
I know they are useful caches, but can we give it a limit space or give it a survival time or something else?
Copied from original issue: microsoft/vscode#24666
Activity
fbricon commentedon Apr 13, 2017
Wow, indeed, the workspaceStorage grows freakingly fast. My 13 workspaces eat up to 3.5GB :-/
This is caused by Eclipse JDT new Java index . There's nothing much we can do at that point about limiting its size, other than disabling it completely, which is not something I'm too keen on doing (i.e. exposing another eclipse internal). I'll ask the JDT team about it
gorkem commentedon Apr 13, 2017
Larger index files vs speedier searches was a design decision. I do not think this is a performance problem though.
fbricon commentedon Apr 13, 2017
So I commented on Eclipse Bugzilla.
Turns out even disabling the index will not prevent the index.db creation.
fbricon commentedon Nov 14, 2019
@rgrunber brings us hope with his work on JDT shared indexes:
fbricon commentedon Sep 14, 2021
@rgrunber https://twitter.com/artursignell/status/1437817323574943748 reminded me of this issue. We should prioritize this work in the coming sprints
rgrunber commentedon Sep 17, 2021
I'm going to close this issue as it was originally filed against the
index.dbfiles generated by the new index. Lately they should not be generated as the new index was disabled (for not providing the kind of performance boost that was expected), so we're back to the old ${checksum}.index files, which we can address in the recently filed #2110.sguillia commentedon Oct 11, 2021
Hi
redhat.java 0.82.0 is taking several gigabytes of storage
Storage contains big files like
624288547.indexand4.tree. Example:Is this expected behavior? If so, could the extension be configured to
Thanks for your help
rgrunber commentedon Oct 27, 2021
@sguillia yes, that's what we're planning in #2110.
I think the first part will be to create some setting option that clears out older workspace storage locations (eg.
$HOME/.config/Code/User/workspaceStorage/x/1/jdt_ws) that are have not been accessed for over some configurable period of time. Any of the data deleted, is simply cached data that could be re-generated when the project is opened once again. It would only take a bit longer to generate.The second part would be to take advantage of some capabilities we have to share indexes across projects, where possible.