Improve stream rendering performances

[satabin]

This change addresses #634 in two ways:

• A change to the generic pretty printer that allows to avoid:
  • Boxing of integers when computing the layout
  • Instantiating many tuples that are immediately discarded
  • Creating intermediate chunks by fusing the annotation and rendering phases
• Re-introduce a direct compact rendering for JSON, that is way simpler than leveraging the generic printer with no groups

By doing so, the compact rendering should be back to the performance in 1.10 and the pretty case is improved a bit.

Here are some benchmark results with the compact rendering in 1.11.1 as the baseline. 1.11.2 represents the results with this change.

xychart-beta
  title "Rendering of int array"
  x-axis ["Pretty 1.10", "Pretty 1.11.1", "Pretty 1.11.2", "Compact 1.11.1", "Compact 1.11.2"]
  y-axis "Factor" 0 --> 1.2
  bar [0.02, 1.12, 0.71, 1, 0.004]

Loading

xychart-beta
  title "Rendering of int object"
  x-axis ["Pretty 1.10", "Pretty 1.11.1", "Pretty 1.11.2", "Compact 1.11.1", "Compact 1.11.2"]
  y-axis "Factor" 0 --> 1.2
  bar [0.01, 1.11, 0.85, 1, 0.01]

Loading

[satabin]

@recons This PR should solve your problem with compact rendering once merged and released.

[ybasket]

Looks good, just few minor comments.

[ybasket]

Suggested change

	(List
	.range(0, 1000000)
	.map(i => Token.NumberValue(i.toString())) :+ Token.EndArray))
	(List.tabulate(1000000)(i => Token.NumberValue(i.toString())) :+ Token.EndArray))

Minor, but IMHO, that makes the intent a bit clearer.

I also would love to avoid appending to that long list, but I assume you want a single chunk? Otherwise using Stream's ++, this could be simplified further.

[satabin]

Yeah I want a single chunk, to see the overhead in processing one chunk.

[ybasket]

Do we have a better option than silently ignoring this bug? fs2 itself uses assert() to catch some bugs – not cool because AFAICT here we would still produce a semi-valid result, but let's at least have the discussion (and maybe a decision for all of fs2-data).

[satabin]

Yeah, I don't like cases like this one, where we cannot statically ensure never happen. And I don't like crashing with an assert either. I will try to find something better here. But it was already like that before 😬

[ybasket]

Do you think a StringBuilder that is allocated to the right capacity could help speeding up here? Like first append the head, then indentSize spaces?

[satabin]

I was think it would actually be way better to cache the padding. In a structured data rendering the same indent size will be found over and over again. I will try to reuse the padding that was already encountered for a indent depth, rather than this.