Emmet - a perf hooligan?

[jrieken]

The top 5 of extensions blocking the extension host process has a newcomer and that's emmet. In 1.31.1 it was top 20, with 1.32.3 it 2nd with 26037 hangs over 5 seconds. I don't have a profile at hand and I also don't use emmet but looking at its implementation might explain it, esp since it doesn't do things in LSP-style but in-proc, e.g probably slowing everything down when a file is large/huge

[octref]

Likely the cause of #70371, will investigate.

Emmet re-parses the file on each edit to determine which region (html attribute? html attribute value? css-in-html? jsx in ts file? css property?) emmet is in.

IMO the proper solution would be either having an API where extensions can figure out regions, but we have decided to not expose TM scopes to extensions.

The alternative is to have emmet hook into the on completion visitors of each LS. I remember @ramya-rao-a said there was issues with JS/CSS LS and with completion trigger characters.

[ramya-rao-a]

@jrieken When you say "top 5" and "top 20" is this something coming from the users or telemetry or your local usage?

@octref
AFAIK Nothing has changed in terms of emmet parsing files in almost a year, so what can explain the sudden change?

Regarding the alternative for emmet to hook into html and css completion providers, we did find good results with html, but not with css. The css language server is not great in identifying the right places where emmet should kick in, especially in in-complete css files. Please see #29113

[octref]

@ramya-rao-a I'll see what has changed. The only one I recall is #68326, but that's related to wrapping not typing emmet abbreviations in general. Thanks for linking #29113 too.

I'm also interested in the full list.

[octref]

Using @emmetio/html-matcher to parse the HTML source of https://microsoft.github.io/language-server-protocol/specification takes 2-3 seconds. That's happening for each document change.

In comparison, HTML parser took between 50-100ms.

[octref]

@ramya-rao-a Wondering what's the original reason for choosing @emmetio/html-parser instead of using vscode-html-languageservice. I think the proper solution to #70371 is either replacing the parser or do incremental parsing by:

• Look at changes
• Find closest ancestry html node that contain the changes
• Only use the parser to parse that region

[ramya-rao-a]

@octref The issue you linked is to a non emmet problem, can you link the right issue?

From what I recall, we had good results from moving emmet completions for html to the html language service. What didn't work out well was the move for css/scss/less etc. And the call we took at the time was that we either move both or none at all.

The only caveat with moving to html language service is the problem of how to support emmet completions in non html files

[octref]

Fixed link.

We can just switch to using the html parser, which seems to be much faster than emmet's, and still keep emmet as a separate extension.

[shepelevstas]

Is it solved? I just updated to the latest version and it fills like emmet got slower.

[Download]

According to this issue it should be fixed:
#70371

[octref]

I fixed two major perf issues for emmet. Think those are the most common cases for hangs (completion, tab-expansion).

Look forward to see a new list of hooligans.