generator support: eliminated performance sink in 'node-processor', solves #1293

[sailingKieler]

• added content length tracking to avoid repeated string concatenation under way

[dhuebner]

That why I prefer to have a get or compute in names to make it clear there are things happening. Where this.content.length looks like a simple field access.

[sailingKieler]

Indeed. 💯

[goto40]

Good work @sailingKieler !!

The patch fixes the performance effect:

• Prior to the patch the performance was very slow (see Performance of CompositeGeneratorNode for large outputs #1292) and hat a O(N^2) characteristic regarding the number of generated lines (in presence of indentation).
• Now it seems to be linear (as expected) and much faster.

Timings with my example now:

nb lines	time in sec to produce input	time for toString
3'200'000	0.7	2.7
1'600'000	0.3	1.25
800'000	0.15	0.7
400'000	0.1	0.4

This is much better than before:

nb lines	time for toString
8'000	4.0
16'000	16.0

[goto40]

I can also confirm that the output is identical for the example sketched in #1292:

wc -l ~/out_old.txt 
16449 ~/out_old.txt

wc -l ~/out_new.txt 
16449 ~/out_new.txt

diff ~/out_old.txt ~/out_new.txt 
16447,16448c16447,16448
< time to generate text:  0.004 sec
< time to convert text:  16.945 sec
---
> time to generate text:  0.006 sec
> time to convert text:  0.037 sec

[msujew]

Looks good to me as well 👍