Improve fragments rendering workflow [add fragment opcode]

[lifeart]

may be partially related to https://github.com/glimmerjs/glimmer-vm/issues/950

While I'm playing with framework-benchmark, I able to get notable rendering inprovement (20% ?) for initial rendering of long loops.

Created component: https://github.com/lifeart/js-framework-benchmark/blob/8bf66d83a32c8305bff6d6a041ac41e4bb25e621/frameworks/keyed/ember/app/components/fast-each.hbs https://github.com/lifeart/js-framework-benchmark/blob/8bf66d83a32c8305bff6d6a041ac41e4bb25e621/frameworks/keyed/ember/app/components/fast-each.js

Appending & updating & removal works fine, but, row node swapping cause internal error:

I'm wondering, is it make sence to introduce fragment opcode, to have builtin ability to get same approach.

example:

<table>
  <Fragment>
    {{#each this.items as |item|}}
      <tr><td>{{item.name}}</td></tr>
    {{/each}}
  </Fragment>
</table>

Idea is - have fragment node, and perform each insets inside it, and after fragment is closed - append it to parent node

Found some solution, if in-element has internal wrapper, issue does not appear https://ember-twiddle.com/1d9ac0ddf31c4d22381877ee31ada2c2?openFiles=templates.application%5C.hbs%2C

working example:

{{#-in-element}}
<wrapper>{{each..}}</wrapper>
{{/-in-element}}

not working:

{{#-in-element}}
{{each..}}
{{/-in-element}}

[rwjblue]

Can you double check this after #1181 (released in 0.62.4)?

[lifeart]

@rwjblue I will, but MR internals looks not related to such behaviour, just name overlapping

[rwjblue]

it made it feasible to use createInstance: false in a component manager for fragments, thought that would also help perf to some extent

[lifeart]

closing as implemented in https://github.com/lifeart/glimmer-next