Memory Benchmark

[bd82]

The UI5 language server downloads a large amount of UI5 SDK data and retain it in memory.

It would be interesting to discover how much memory exactly is needed to run the UI5 Lang Server.
It would also be interesting to monitor regressions and memory consumption overtime.

[matz3]

I had to disable the extension as it took 450% CPU (2,6 GHz 6-Core Intel Core i7) and over 1GB RAM for a very long time (not just for some seconds/minutes).

[bd82]

Hi @matz3

Can you provide a reproducible scenario?

[matz3]

I could only reproduce it with one quite large project (closed source; I will send you the details via e-mail).

Seems to be related to node_modules folders, probably because they have local symlinks (some are cyclic).
When I remove or even rename one of them, them high CPU usage is gone immediately. When I rename the folder back to node_modules, the problem only comes back when restarting VS Code.

Process is always Code Helper (Renderer).

Maybe this already gives you some hint where the problem comes from.

Here are my VS Code details

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T13:08:29.692Z (6 days ago)
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.6.0

[bd82]

Thanks for the information and initial investigation @matz3 👍

I suspect it may be related to this code snippet

• ui5-language-assistant/packages/language-server/src/manifest-handling.ts

  Lines 80 to 84 in da2682e

  	async function findAllManifestDocumentsInWorkspace(
  	workspaceFolderPath: string
  	): Promise<string[]> {
  	return globby(`${workspaceFolderPath}/**/manifest.json`);
  	}

It is possible we need to glob more "gentle" fashion and ignore traversing symlinks.

Is your use case a common scenario? would many UI5 projects include cyclic folder structures?
Or it unique to you scenario?

[bd82]

I did a quick change trying to exclude node_modules folders from that glob pattern.

return globby([${workspaceFolderPath}/**/manifest.json, !**/node_modules/**/manifest.json]);

Can you try reproducing the issue again with this change (vsix below):

• vscode-ui5-language-assistant-1.5.1.zip
• rename .zip -> .vsix

If you are interested in testing more pattern variations you can build the VSIX yourself in ~1min

• clone repo
• yarn (at the root)
• yarn run build:quick
• cd packages\vscode-ui5-language-assistant
• Take install the VSIX from this folder into VSCode
  • Extensions: Install From VSIX in VSCode
  • `Uninstall the previous version of UI5-Lang-Assistant first...

[bd82]

Relevant code is here: #265

[matz3]

Still the same behavior with your attached vsix file.

Is your use case a common scenario? would many UI5 projects include cyclic folder structures?
Or it unique to you scenario?

I'm not sure about that. Usually this shouldn't happen, but in my case it's like this because of some local linking of npm packages, where I think too many links are created. Per package.json definition there is no cycle between those projects.

Maybe it's also related to the number of manifest.json files within the workspace?
There are several test files within the UI5 Tooling projects, which are cloned into the workspace.

find ./ -name "manifest.json" | wc -l
180

[bd82]

Maybe it's also related to the number of manifest.json files within the workspace?

Perhaps the combination of cyclic folder structure and many manifet.json files is causing a bug with the VSCode
synchronization file events APIs.

• ui5-language-assistant/packages/vscode-ui5-language-assistant/src/extension.ts

  Lines 37 to 39 in da2682e

  	synchronize: {
  	fileEvents: [workspace.createFileSystemWatcher("**/manifest.json")],
  	},

I suppose next steps in debugging would be:

• To remove the synchronization file events pattern and see if the problem reproduces.
• To remove the glob pattern and see if the problem reproduces.

I am however uncertain if we should actually examine this in more depth, as I am not sure if this is a real world scenario, e.g: I used to have performance/infinite loop issues with IntelliJ when I had my own scripts to link packages in a pseudo mono repo. But those have disappeared since I've started using lerna/yarn (in the same project)...

[matz3]

Usually I've enabled all my extensions in all VS Code workspaces.
So the use case here is not that I would like to use this extension with the problematic project.
I just want the extension not to consume such an about of CPU / memory.
But for now I'm okay with disabling the extension for that single project/workspace.

[bd82]

How important is this to you?
I could try re-producing the scenario you have described, but right now I do not have accesses to
that "internal" repo, perhaps I will have access next week.

@matz3 Do you want to do a debug session together?

I could guide you in making some
minor changes and re-building the VSIX so we could get some hints what is the origin of this issue, e.g

• our globbing - (may be able to solve in this case).
• vscode file watcher apis (probably no work around in this case)

[matz3]

To me it's not a priority at all right now.
I sent you a mail on 30th July with details about my internal project. Maybe it didn't get sent properly. I've just sent it again.