Use microtask to flush the write buffer after input

[Tyriar]

Fixes #4158

Previously this was 5000ms+ scripting:

After input:

[jerch]

If latency is your main concern here - I think we can call this._innerWrite() directly here? (after pulling the last 3 lines of the method before the call) I dont see a reason for microtask delegation here, but there is a chance I am overlooking something.

[Tyriar]

Yes you're right, this made more sense in the previous iteration when I was relying on data length instead of the user input signal, will change

[Tyriar]

Needed to duplicate some calls to make this happen, that's one of the reasons why it was microtask

[jerch]

@Tyriar Yepp, the direct call works nice for me.

Also this PR restores scripting time back to old values, my devtools profiling is still screwed up:

Note this huge greyish portion and the overall runtime. Any idea what causes this? Also note that with devtools closed I see normal runtimes. My guess would be - there is another code change, that s*cks really bad on profiler performance, but gets not really resolved by the profiler (thus shown as grey). Sadly this currently makes the devtools profiler unusable for me.

[Tyriar]

I see that every now and then and it's not clear to me what it means. Does reloading the page or devtools help it go away? 🤔

[jerch]

Oh well found the issue - queueMicrotask in server.js basically bypassed the intermediate buffering. Without the tiny buffer there, websocket creates so many messages, that my browser profiler cannot keep up. Its basically a message congestion from too many tiny messages.
I think we need to keep setTimeout there, but maybe with a smaller limit? Like 2ms instead of 5?

Will see if I can fix it with another PR (had to deal with it anyway in another project), for xterm.js side things seem to be fixed with this PR 👍

[Tyriar]

Ah ok, we should tweak that then. Shall we do a very similar change such that we fire the event following incoming data with queueMicrotask/immediate call?

[jerch]

Ah ok, we should tweak that then. Shall we do a very similar change such that we fire the event following incoming data with queueMicrotask/immediate call?

Yepp, should work there too 😺