vscode: Tab key is extremely slow on medium-large files when emmet.triggerExpansionOnTab is enabled

Issue Type: Bug

When I open a large file (tried on .php and .html) and emmet.triggerExpansionOnTab option is enabled, then each pressing on <kbd>TAB</kbd> key (even on blank line) make my computer hung for about 1-2 seconds (depends on file size) with high CPU load.

This is true with current 1.33 version of VS CODE, with or without extensions (tried with code --disable-extensions), with or without project open. I also tried to download 1.34 insiders build and the behavior is still the same.

Steps to Reproduce:

Download a fresh 1.34 insiders build (or use 1.33 current).
Create new HTML file tmp.html with any content. Make sure it is 2000+ lines. Better 5000+ - the hang is more obvious when the file is more large. I attached an example file here.
Set cursor on any line and press <kbd>TAB</kbd>. You can press it many times in a row or press and hold - all should be fine.
Open preferences and enable Emmet: Trigger Expansion on Tab option (emmet.triggerExpansionOnTab).
Return to opened file and try to press <kbd>TAB</kbd> again. You should see a very notable delay between pressing the key and moving the cursor (you can enable Toggle render whitespace option to see this better).

If you press and hold the <kbd>TAB</kbd> key for about 5 seconds, then you should see no spaces/tabs characters entered (but notice high CPU load), you then can move cursor to anoter place in the editor, and after another 10-30 seconds have been passed (all that time with high CPU load), the delayed space characters will appear at the current cursor position (not where the cursor been when you actually pressed the <kbd>TAB</kbd> key).

So here is two problems:

A high CPU load and delay between pressing <kbd>TAB</kbd> key and appearing of spaces/tab characters.
The space/tab characters appears after the delay not where the cursor was when <kbd>TAB</kbd> key was pressed, but at the current position of the cursor.

I notice this problem only recently. I’m not sure with which build this comes in (not used VS Code recently), but 1-2 month ago there were no this problem.

VS Code version: Code - Insiders 1.34.0-insider (56f1b4795fed05677eb82a21dac4fc1ab62d747b, 2019-04-09T05:19:45.294Z) OS version: Windows_NT x64 6.1.7601

System Info

Item	Value
CPUs	Intel® Core™ i5-4670 CPU @ 3.40GHz (4 x 3400)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	23.93GB (1.39GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions: none

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 12
Comments: 19 (11 by maintainers)

Commits related to this issue

Part of #71996 — committed to microsoft/vscode by octref 5 years ago

Most upvoted comments

Don’t worry, i started use PHPStorm, so this bug can be leaved for another one year =)

medzhidov on Dec 10, 2020

I made a cheap improvement, which is to disable expansion if the previous character is space or tab. For example div| expands, but div | doesn’t. This makes tabbing on empty lines not that miserable, but a proper fix is still needed for the expansion.

octref on Sep 3, 2019

@octref Tried today’s insiders build. Nothing is changed.

I opened a html file with 3700 LOC, enabled emmet.triggerExpansionOnTab, and tried to press <kbd>TAB</kbd>. It extremely slow and consumes high CPU. For doing nothing (nothing to expand by emmet because I press <kbd>TAB</kbd> key on empty lines…).

Also, it can be not a duplicate of #70371 because in #70371 there is no high CPU load and there users try real emmet expansions. This bug on other hand not about emmet expansion, but about pressing <kbd>TAB</kbd> key on empty line (where emmet should not trigger at all). Not only on empty lines I must say, but on non-empty lines too.

It also has nothing to do with HTML. I tried to open a large PHP file and it has same problem.

VS Code version: Code - Insiders 1.37.0-insider (cf03ea3729dc37e439d724267ad29dc5840f903a, 2019-07-30T07:15:22.972Z) OS version: Windows_NT x64 6.1.7601

System Info

Item	Value
CPUs	Intel® Core™ i5-4670 CPU @ 3.40GHz (4 x 3400)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	23.93GB (2.88GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions: none

xak2000 on Jul 30, 2019

@rzhao271 I checked out the file tmp.html that I included in the issue description and no, it doesn’t occur anymore if I press and hold <kbd>TAB</kbd> on an empty line.

But I managed to reproduce the issue in other way.

Open preferences and enable Emmet: Trigger Expansion on Tab option (emmet.triggerExpansionOnTab).
Put the cursor at the start of an empty line of tmp.html file (e.g. on line 11).
Enter div and press <kbd>Esc</kbd> to close the autocompletion popup menu.
Press and hold <kbd>TAB</kbd> for 5-10 seconds. Release it.
Nothing new will be entered in the editor (emmet expansion would not happen) in next 10-20 seconds (one expansion sometimes still happens so one instance of <tab></tab> text could appear), but you will notice one CPU thread that consume 100% CPU. Main editor thread is still responsive, I suppose. I can move cursor to another line and enter some new text here etc. It looks like VS Code is not frozen at all. To notice that something is wrong I needed to look at my CPU temperature and frequency and I see that it doing some hard work. And then after 10-20 seconds suddenly emmet will finish it’s expansion and something like this will be printed in the editor at the location of cursor when you held TAB:

<div>|</div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>v></div>

(the | indicates the cursor location).

And what is worse: cursor will be moved back into the position of the file when you held <kbd>TAB</kbd> (after first <div>). Even if you already was in another place of the file and entering some text at the moment, your input will be interrupted and part of text that you entered will be placed into the new position of cursor (after first <div>).

xak2000 on Dec 10, 2020