IntelliSense is painfully slow #5063
Comments
|
Is it a new project without any dependencies? |
Ah sorry, I thought I included my packages. No, it's not fresh. It's a Nuxt project: |
|
Could you install a VSCode extension called Volar Labs to check the memory usage?
|
|
It spits out an HTML file, is there an easy way to share that? |
|
How much memory did it use in total?
|
|
200MB: |
|
I have similar issues.
|
I think this refers to the total memory used by the TS server. It would better to check which libs are consuming a large amount of memory and consider whether alternatives can be found. |
|
@rigtigeEmil Could you provide a minimal reproduction for investigation? |
|
@KazariEX I will try when I'm home later. Do you have an idea of what could be the cause of the issue? Do you expect it's one of the packages? Maybe @ludwig801 has a repro he can share now? |
|
It might not be a memory issue for you, but rather a problem caused by some typescript issue, or it could be something else. |
|
I know it's fairly anecdotal, but I saw a few other mention a similar issue in the discord channel associated with language-tools, so it might be a common problem. |
Unfortunately I cannot share my repro, and it seems that this does not happen in small projects... |
|
@KazariEX is there any way to debug this in my project, and figure out what's going on? I've tried in a small replication with the same packages, and while the intellisense is not immediate, it's nowhere near as slow as in my real project. In my dummy-project I get completions within a reasonable time (100ms~maybe), although not immediate like I've experienced before |
|
If you choose to prioritize troubleshooting typescripts, you can try removing files one by one (dichotomy?) from tsconfig and check if the speed of intellisense has been improved. |
|
@rigtigeEmil you should gradually eliminate the differences between the two projects through dichotomy and confirm the minimal differences that cause performance problems. Even if we conduct remote investigations, we only do the same thing. Many of the performance reports we received were ultimately found to be caused by project dependencies or poor TS code. @ludwig801 project size is usually not the reason, even in TypeScript's checker.ts with 50,000 lines of code, autocompletion can be completed in a few hundred milliseconds. Like I said above, you need to find which differences causing the performance issue. |
Is there a way to get debug information out from the extension? About which file(s) could be causing it to hang, if it's some files in my project that are causing the issue? |
|
I'm having this issue as well. Usually when I first load my project, IntelliSense can feel relatively snappy, but as I move through files in the project, the language server will start to take several seconds / minutes to catch up with the edits I've made, or an autocomplete prompt I'm asking for. Now, I have an idea why this might be happening, as I am also working on a Nuxt project, with auto-imports enabled, but also a generated Prisma client. Here I've followed the instructions which @KazariEX provided, and ended up with this.
As I thought, the auto-generated Prisma declarations file is extremely large in comparison to everything else in my project, but I honestly don't know how I could work around it. Excluding the file manually in It's been an issue with large Prisma projects for a long time, and I imagine the fault lies with the fact that they are keeping the generated types as a single file, regardless of size. It's not like I can just get rid of Prisma altogether, as I am using it on the server side of my app and inside of my client side to help with matching the types of my inputs to the server and its outputs, and I am well into my project's development at this point. So, I am a bit at a loss as to how to proceed, it's been difficult to keep a steady development pace, having to sometimes sit there waiting for my editor to get going. If I could just throw more RAM at the language server, I would, but it seems like it's limited to only 4 gigabytes. EDIT: For now I am going to try using https://github.com/HRM/prisma-nitro-patcher to see if it makes any difference, and/or disable my Prisma client extensions for the time being, as I've been reading in this issue that it could be a reason for performance issues. |
I understand this. The problem is that this only happens in Vue projects. In TS-only projects I have no problems with performance whatsoever. Seeing that I'm creating SFC the way I supposed they are to be created (following the official Vue docs) and that I'm importing stuff and doing everything that I'm supposed to, I have to conclude that this issue arise from the Vue language tools and it's way of handling either TS, <script setup> or something other from the language itself. In sum, I believe I'm not doing anything wrong with TS, since I have other large TS-only projects working just fine, and without a way to properly debug problematic files or common pitfalls that one might be falling into, it's difficult do understand where the problem might be in a project with 1000+ files/components. |
|
Before the actual inspection, no one can assert that he has not made any mistakes. And dichotomy is already a very practical debugging way. |
Perhaps, for a small project. For a full platform, such as is my company's case, is a huge pain in the neck with countless hours of debugging and no assurance of an answer. I'm not trying to be difficult or snappy, but I have to realistically consider the following: this only happens in a Vue project, with the Vue Language Tools - surely it is common sense to believe that it is not my TS scripting capabilities that are at fault here since, as I've mentioned before, I have other full-fledged TS projects which present no issues at all and are quick and performant when editing. |
|
If there's a way to extract more debugging information, it'd be much easer to try and debug on my own, but it's quite a big ask to "try removing stuff until it works". I've invited @KazariEX to a private fork of a minimal version of my own project, and they've confirmed they see the issue too. I also have no issue with the completion when this extension is not installed, so normal TS IntelliSense is working, outside of Vue files |
|
I just drop the |
This folder includes type definitions from the backend. It's not particularly large, so it's confusing to me why it'd cause issues. I'd guess it includes perhaps a few hundred types, but is that low amount of type definitions expected to cause issues? |
|
This is not closely related to the amount of code. It's more likely caused by poor TS code. |
|
What's considered poor TS code to the point where it can cause this large of an issue? This code is purely auto-generated, so I won't attempt to exclude the possibility that something could be improved |
|
@KazariEX @johnsoncodehk Based on this thread, do you not believe there is an issue here, or do you need more information from me? |
|
We have identified the problem and are working on fixing it. |
|
Do you have an inkling to when a fix will be ready? |
|
I have similar issues too. |
This is caused by the combination of element plus and project scale. Have you enabled |
yes |
|
Does the latest version solve this problem? |
For my part, the latest update has only solved a few issues I had with auto-closing of HTML tags and automatic addition of " quotes to HTML attributes, which, due to the latency, would also take a long while. Regarding the slow intellisense, as far as I can tell, there is no measurable difference.
This last point is important, for me, because it seems to highlight something which confuses me: when I import a Vue SFC into another SFC, using <script setup> syntax, what kind of import is this? How does it translate into performance loss? I would think that this is would be only like importing a TS type, since the vue files are compiled into their sibling TS type declarations, no? It seems that the more "depth" you add to the import tree, the more a single file can crawl to a halt. |
|
It is possible that we generated some poorly performing virtual code while const foo = {
...{} as TypeA,
...{} as TypeB
};When the spread type contains many properties, this syntax may cause significant performance degradation. In the past, we widely used this way to effectively override duplicate declared properties, rather than using intersection to potentially merge types. But now we believe that duplicate names are something users need to avoid. |
|
@ludwig801 Would you be willing to provide a repo that can reproduce performance issues? I no longer feel any significant performance issues on @rigtigeEmil's repo, but I believe we still have a lot to do on larger projects. |
|
This is Vue Official version 2.2.0, still slow. |
Why are there so many random string folders in the views folder? |
Those are the pages that are automatically generated with code. |
|
If you don't need support for their types, you can choose to exclude these files in tsconfig. We may be powerless to address the performance issues caused by element plus (or other ui libs). |
I'm sorry, but I didn't understand you completely. |
Oh man, I would really like to be able to do that, but unfortunately this is a company repo, and I cannot share it outside the company... If I have the time. I shall try to create a bit enough project for this, but it's really hard to do so now. Are there no plans in the future for debugging features within the extension itself? Something like log dumps or traces which would allow a user to submit information regarding performance in an "Anonymous" way without having to share project-sensitive information? |
Such as: declare module 'vue' {
export interface ComponentCustomProperties {
foo: string;
}
}
const foo = 1;Now the type of |
Wow, ok, that's a weird one. Otherwise one does stuff that seems perfectly valid (and maybe it will be in the future, but not for now) and ends up with a snail of a project 😅 |
Vue - Official extension or vue-tsc version
v2.1.10
VSCode version
1.96
Vue version
3.5.13
TypeScript version
5.7.2
System Info
System: OS: Windows 11 10.0.22631 CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor Memory: 35.22 GB / 63.91 GB Binaries: Node: 20.10.0 - C:\Program Files\nodejs\node.EXE Yarn: 1.22.22 - ~\AppData\Roaming\npm\yarn.CMD npm: 9.6.6 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: Chromium (127.0.2651.74) Internet Explorer: 11.0.22621.3527package.json dependencies
No response
Steps to reproduce
Intellisense is slow both in template and in script parts of Vue files. I've had a look at the output, and it seems a bunch of the requests are taking a long (multiple seconds) time.
The only thing I'm doing in this test is writing
<div, expecting the tag to be closed automatically, and waiting. I see similar results, of requests taking a long time when editing the script part, or anything else essentially.What is expected?
Intellisense is completing within a reasonable time (100ms?), both when editing template and script
What is actually happening?
Intellisense is extremely slow, often taking 10s of seconds before completions are available
Link to minimal reproduction
No response
Any additional comments?
No response
The text was updated successfully, but these errors were encountered: