Optimize gc from decoration-related hot code paths

[Tyriar]

Fixes #4079

Before:

After:

[jerch]

@Tyriar Maybe related (and maybe already fixed?) - when doing some perf benchmarks with canvas renderer I found this to be quite expensive (up to 25% of the renderer runtime):

xterm.js/addons/xterm-addon-canvas/src/TextRenderLayer.ts

Line 190 in 4effa38

this._decorationService.forEachDecorationAtCell(x, this._bufferService.buffer.ydisp + y, undefined, d => {

I did not look at the code in detail, so I dont know what causes the high runtime for sure. I saw that there are some iterators/generators, maybe those are already the culprit? (They were a real showstopper in the past, but I think engines got alot better in handling those in a speedy manner). Since I had no decorations in place at all I wonder if there is at least an early fast exit possible to cut off most of the code path.

[Tyriar]

@jerch it should be much faster now that it's forEach instead of the old iterator. The overhead was creating 2 iterators for each cell getting updated. Lovely to use but way too slow to create in this hot code path.

I've finished all the gc-related fixes if you want to re-try any tests.

[jerch]

@Tyriar Oh well, I meant the getDecorationsAtCell above (wrongly linked to the new impl). The forEach impl is indeed alot faster (<<5% of renderer runtime), which is somewhat sad, as the yield code reads much nicer (at least for me coming from python).

The w object is an interesting hack around the gc - is that still needed with the forEach way? Would have thought, that the gc can simply fast collect it here not creating any overhead (other than with generators, where the shadowed stack frames created from yield state add more overhead for the gc).

Anyway - perf issue is fixed 👍

[Tyriar]

The work object is a common trick we already used, just new bits were added since. I don't know exactly what variables are optimized away, but for (int i...) for example ends up causing minor GCs