markdownlint performance issue #291
Comments
|
VS Code should have also provided you a performance trace file to attach. Without that, this is not actionable. Unless you can reproduce it consistently and describe how? |
|
Well I had hoped everything relevant had been included since I generated the issue using the link provided directly from the performance window itself. I can look for the problem again tomorrow, if you tell me how to grab a trace file (my initial Google didn't tell me). (I'll just add that I saw this while I was trying to figure out why performance was bad, and I am not entirely convinced the performance problem was markdownlint. But the performance window did indicate a performance issue with markdownlint, so I thought it was worth reporting. My suspicion is that the real bottleneck is vscode's own markdown services.) |
|
I hope it's not my fault, but it could be! In the past, people have attached a CPU profile like is discussed near the middle of this article: https://github.com/microsoft/vscode-wiki/blob/main/Performance-Issues.md There was an issue in the previous release where certain tables could be very slow to parse, but that should be much improved in the version you're using. |
|
Attaching cpuprofile. |
|
Thanks! I had a look just now. It seems VS Code clumps all the extension activity into a single trace. It looks like you had at least one other extension active at the time of the trace, MarkdownTocTools? If you look at the trace, Markdownlint's frames show up attributed to "bundle.js" instead of "extension.js" and do not make up the highest CPU consumers in that trace by self or total time. If you're able to reproduce this slowdown, please do so with other extensions disabled (especially Markdown-related ones) and let me know if it's a particular scenario that's most problematic. |
|
So I ran the bisect a/b testing tool (which I should have done to start with), and it identified a different extension (which shall remain nameless) as the guilty party. I've already reported it to them. At this point I think we can presume it's not your fault. But I reserve the right to complain about something else in future. :-) |
|
Permission granted! :) And thanks. |
|
Also, I appreciate this pleasant support experience. I'm a former dev myself, and now my hobby is reporting bugs. It isn't always a rewarding hobby. :-) |
|
LOL. It's nice to get a detailed report like yours instead of something that's just "It's broke. Fix it!". |
|
So it is my duty to report that I believe there is still a performance problem with markdownlint. I previously disabled the extension that was the primary problem (other people have also complained about its performance). But I still see some lag in the editor. It goes away when I disable markdownlint. And it comes back when I re-enable markdownlint. I have a suspicion that the files it balks on are those with a lot of headings. For example, right now I'm seeing it in a file with 13k words and 67 headings. |
|
Please link to an example that demonstrates the problem. I can profile it to see why it's slow. Regarding editor behavior, there is a brief delay between when you stop typing and when the linting occurs. This is intended to avoid interfering with the typing process. If the slowness you're seeing isn't consistent with that, something else may be going on. |
|
No it's definitely not that the linting is slow. In fact I have configured it to only lint on save. It's that the editor lags responding to typing or pasting text. I'll see if I can post a repro doc for you tomorrow. |
|
I can review the code, but in the scenario you describe there should be very little happening in the extension on each key press and during editing. |
|
Yeah that makes sense. One thing I forgot to mention is that I have vscode configured to save when the document loses focus. Which makes me think that I generally see the lag when I'm flipping back to a file either to paste something I've copied from somewhere else or to start typing, which maybe means the linter is still busy from the operation kicked off when I flipped away from the doc? |
|
That would make sense. Assuming this isn't an issue with small simple documents, it would be helpful to get a link to one of the documents that demonstrates the slowness. It's entirely possible there is especially bad behavior under some circumstances. |
|
I did a little experimentation, and I don't think my hypothesis holds. But I'm attaching a demo doc that shows the problem. I've munged the text. |
|
I played around with insiders build and vscode.dev a bit. I can't repro the problem consistently. Which makes me think there could be a problem interactions between extensions. (I do have a lot of extensions installed.) |
|
Any further thoughts on this issue? It's really painful. All I can tell you that if I disable markdownlint the lag in the editor disappears. Is it possible that the extension is ignoring the markdownlint.run setting? Here's my user settings: "markdownlint.config": {
"MD007": false,
"MD010": false,
"MD011": false,
"MD024": false,
"MD025": false,
"MD026": false,
"MD028": false,
"MD029": false,
"MD033": false,
"MD034": false,
"MD035": false,
"MD036": false,
"MD037": false,
"MD041": false,
"MD045": false,
"MD053": false
},
"markdownlint.focusMode": true,
"markdownlint.ignore": ["*.txt"],
"markdownlint.run": "onSave", |
|
Profiling the file you provided is near the top of my TODO list. However, the fact that you can only reproduce this in one of three configurations and then only randomly makes me think it's not a parsing slowdown. I also haven't heard this from other people which makes me think it's not widespread. There is some chance this is all due to some weird state that your instance of VS Code got into - have you tried reinstalling? |
|
I'm reluctant to do that, just because it's such a pain. I think the issue is probably that I work with pretty big files with lots of markup. In case it's any diagnostic use: I typically work with the markdown preview open to the side and the file explorer or doc outline or some other panel open on the other side. However I haven't noticed that closing either of these makes any difference. |
|
I looked at this a bit last night in a profiler. I didn't see anything unreasonable about your file, though I should be able to improve performance a bit. However, I don't think it will help your scenario since that same file works fine for you on the same machine using the Insiders build (and viscose.dev). Insiders is very same app as the official VS Code release, so my assumption is that something about your VS Code configuration is leading to this. You might try commenting everything out in the user settings JSON file (or renaming it) as an easy way to revert to default and try like that. |
Good idea. I just tried it. Sorry, it didn't help. Also re insiders build: I did some more testing. Before, I just fired it up and installed the linter, so I had a pretty clean environment, and use it for a few minutes. I've just done some more testing: copying over all extensions and settings from my regular environment and the behavior is just as bad as in the regular environment. But as soon as I disable markdownlint the performance of the editor improves dramatically. |
|
What I don't understand is why markdownlint is fine in isolation, but then you add a bunch of other stuff and things get slow - but removing just markdownlint makes it fast again. There seems to be some kind of interaction with something else you've got running. I'd think that other thing could be identified by similar process of elimination. |
|
That makes sense to me too. Can we DM on github? DM me if you think it would be helpful to chat. |
|
FYI, I've made a few changes to improve performance in the |
|
Grand. I'll give it my stress test as soon as I get the update. :-) Re reproducing it: Maybe I could send you a vscode profile? That would get you the extensions I'm using, then you'll probably see the performance impact. Because I more and more suspect that the actual problem is that a lot of extensions that could be doing some or all of their work async are not, and they're blocking the editor thread. So even extensions like MDL that are async, but are also doing lot, are still being impacted. Since I've been paying special attention to this problem lately here's another weird little clue I noticed: hitting the return key usually has a much more noticeable delay than just typing text. So what's happening when a new line is added to the file? Not saying it's MDL has anything to do with it, but that whatever is blocking the editor thread obviously affects all the extensions that use the editor. |
|
Sure, I could look at a profile of this - please link to a new one of the relevant behavior. I tried to reproduce this myself and couldn't. I reviewed the code that might run in your scenario and came up with one thing: could you please try removing your configuration for Probably not relevant, but your |
|
I changed markdownlint.ignore and markdownlint.focusMode but it didn't help. What's the best to get a profile to you? |
|
This update includes various performance improvements to It sounds like it won't affect your scenario, but it'll be interesting to try once I publish a new version. |
|
FYI, version |
|
The performance seems better, but variable. Right now what I'm seeing is that the editor is especially laggy when I'm working in a markdown file with a lot of HTML markup in it. But again, if I disable the mdl extension, performance is instantly better. For example, the file I'm working in today has about 2500 lines, 15,000 words, and 1000 html tags. |
|
If you're able to reproduce this on another machine, I'll try to investigate! So far, it seems like it could be limited to your VS Code install. (Not specifically your machine, either, since it works okay for you with the Insiders build and vscode.dev.) |
No, as I explained before this is not the case. At first I thought so, but I only did a quick check. When I went back and used insiders for more than a minute I started to see the same lagging behavior. In any event the behavior is exactly the same both on my SurfacePro laptop and my beefier mini computer. |
|
Right now, I don't have enough to go on. If you are able to figure out what provokes this behavior, maybe we can exaggerate that so I can see it and investigate. Or if you are able to get a CPU trace from VS Code, That may be useful (though they tend to lump extensions all together). The good news is that general performance improvements also help your scenario and I will continue trying to make things faster when I can. But without something to go on, all of my guesses so far have not been helpful here. |
|
I understand. It's the devil. I've been trying to find the simplest repro I can. But it seems like there's no one extension that is the problem, but having a number of extensions. At a certain point it just breaks down. Turning off MDL only seems to fix it not because MDL is misbehaving but because it is an especially process-heavy extension. My only idea is that I can send you a symptomatic file and a profile. Maybe if you load that up, you'll see the issue. |
Type: Bug
Running extensions reports a performance issue on this extension.
Extension version: 0.51.0
VS Code version: Code 1.80.0 (660393deaaa6d1996740ff4880f1bad43768c814, 2023-07-04T15:06:02.407Z)
OS version: Windows_NT x64 10.0.22621
Modes:
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
A/B Experiments
The text was updated successfully, but these errors were encountered: