search

SAP / ui5-language-assistant

VSCode Extension and Editor Tooling for SAPUI5
Apache License 2.0
54 stars 25 forks source link

Memory Benchmark #247

Open bd82 opened 4 years ago

bd82 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Hi @matz3

Can you provide a reproducible scenario?

matz3 commented 4 years ago

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 commented 4 years ago

Thanks for the information and initial investigation @matz3 👍

I suspect it may be related to this code snippet

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 commented 4 years ago

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):

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

bd82 commented 4 years ago

Relevant code is here: https://github.com/SAP/ui5-language-assistant/pull/265

matz3 commented 4 years ago

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 commented 4 years ago

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.

I suppose next steps in debugging would be:

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 commented 4 years ago

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 commented 4 years ago

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

matz3 commented 4 years ago

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.