Add Event.defer with hidden experimental setting

[Tyriar]

Part of #161622

[Tyriar]

I found that about 20-30% of keypress time was spend setting up or tearing down timeouts/callback. This change introduces Event.defer which now is now a convenience function on top of Event.debounce which converts it to a debounced signal. It converts some low-risk listeners which simply schedule things to a following task to use deferred listeners to avoid creating a new timeout for each one.

Before:

The above was taken using the current change but swapping out defer's implementation with signal(event) to get an approximation of what it was before.

After:

This was tested on my fast machine so the numbers are pretty small, they get quite a bit larger on slower hardware. Async stack traces were disabled to get more accurate timeout measurements.

[jrieken]

Thanks for kicking this off. It's an interesting approach to debounce at the emitter and not at listeners. I believe either works and I let @alexdima and @hediet decide what they prefer. I do see the advantage of such an offering - it is a nice and central invitation/reminder to be a nice listener

The disposable store for the defer util is important and shouldn't be forgotten

[jrieken]

Needs to have the ability to be created with a disposable store (see other utils and doc) because otherwise a leaked listener keeps this alive

[Tyriar]

👍 will keep in mind for next iteration

[jrieken]

Needs to pass this._store to dispose this event when the editor is dispsoed

[jrieken]

This listener is already async (TimeoutTimer#cancelAndSet) and I don't think double debounce is needed

[Tyriar]

This was what I was trying to avoid, deferring the extra clear and timeout calls into the existing timeout, but it didn't give the gains expected.

[jrieken]

again double debounce?

[Tyriar]

Making this a draft again, still measuring differences

[Tyriar]

Some measurements via performance.now() (0.1ms precision):

Typing 'a' on my macbook until line is full (to avoid scrolling overhead), ignore first 10 samples as suggest is involved

PR where defer uses debounce

averageWithoutFirst 2.341666666428662 sample size 144
averageWithoutFirst 2.2861111108731063 sample size 144
averageWithoutFirst 2.3076388886612325 sample size 144
averageWithoutFirst 2.353472222470575 sample size 144

PR where defer uses signal

averageWithoutFirst 2.33819444430992 sample size 144
averageWithoutFirst 2.392361111162851 sample size 144
averageWithoutFirst 2.3055555556072957 sample size 144
averageWithoutFirst 2.3951388884128795 sample size 144

main

averageWithoutFirst 2.3451388888578446 sample size 144
averageWithoutFirst 2.400694444672101 sample size 144
averageWithoutFirst 2.347916666366574 sample size 144
averageWithoutFirst 2.1895833337265582 sample size 144
averageWithoutFirst 2.425000000020696 sample size 144

These results show that it may be slightly faster, but not as much as I was expecting.

I notice the JavaScript Profiler is far more accurate than the Performance tab in devtools for measuring this low level stuff so I should probably be using that to analyze. It also seems to avoid the timeout overhead problem. Closing this for now, will investigate further.

[jrieken]

I notice the JavaScript Profiler is far more accurate than the Performance tab in devtools for measuring this low level stuff

Yeah, that matches my experience. Tho, it lacks the holistic view of things

[Tyriar]

Did more thorough performance testing using a JS CPU profile, couldn't see a particular difference with this change of tweaking how scheduling things was done.

Details

Some more measurements, this time using JavaScript Profiler on a profile with the following test:

• Make InputHandler.ts (xterm.js) dirty
• Reload
• Wait for renderer to calm down
• Type a 150 times at the bottom of _preserveStack

Before - main

Profile:

codeEditorWidget.ts:1616 = 9.37% of keypress fn

Focusing on that function:

After - Event.defer

codeEditorWidget.ts:1619 = 9.36% of keypress fn

Focusing on that function: