Limit Extension storage usage

[jrieken]

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

[fbricon]

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]

Larger index files vs speedier searches was a design decision. I do not think this is a performance problem though.

[fbricon]

So I commented on Eclipse Bugzilla.

Turns out even disabling the index will not prevent the index.db creation.

[fbricon]

@rgrunber brings us hope with his work on JDT shared indexes:

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=515268
• https://rgrunber.fedorapeople.org/jdt-shared-index.mp4

[fbricon]

@rgrunber https://twitter.com/artursignell/status/1437817323574943748 reminded me of this issue. We should prioritize this work in the coming sprints

[rgrunber]

I'm going to close this issue as it was originally filed against the index.db files 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]

Hi

redhat.java 0.82.0 is taking several gigabytes of storage

Storage contains big files like 624288547.index and 4.tree. Example:

.config/Code/User/workspaceStorage/x/1/jdt_ws/.metadata/.plugins/org.eclipse.jdt.core/624288547.index

Is this expected behavior? If so, could the extension be configured to

• clear its cache when it exceeds a certain size,
• write on an external device,
• or do not produce big files in the first place?

Thanks for your help

[rgrunber]

@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.