Ember.js: Regressão de tamanho de ativo na v3.17.0

Pode confirmar em um novo projeto de brasa:

__2.16.0__

• fornecedor: 692,58 KB (176,09 KB compactado em gzip)
• aplicativo: 9,82 KB (2,15 KB compactado em gzip)

__2.17.0__

• fornecedor: 715,12 KB (183,64 KB compactado em gzip)
• aplicativo: 9,94 KB (2,2 KB compactado em gzip)

Fez alguns diffs fornecedores e parece ser causada por algum vislumbre-vm atualizações, por exemplo https://github.com/glimmerjs/glimmer-vm/commit/4c56c216465410f5bd6f4f53fb7d4508f8048f09#diff -64c3cabffb164d9a2c4bf2d427094e19 via https://github.com/emberjs/ ember.js / commit / 699439c0aaa1917754490efeb5751d10f77e5230

O mesmo aqui.

2.16.3

• fornecedor: 886 KB (brotli de 213 KB)
• app: 1,01 MB (126 KB brotli)

2.17.0

• fornecedor: 907 KB (219 KB brotli)
• app: 1,15 MB (137 KB brotli)

Além disso, notei uma degradação de desempenho de ~ 5% em nossos testes de integração indo de 2.16.3 para 2.17.0.

PS @ Turbo87 - poderia ser por causa do HBS ? Eu também estou usando. Ele poderia ter "quebrado" de alguma forma para os novos modelos gerados pelo Glimmer VM atualizado?

@ boris-petrov - Importa-se de verificar isso para nós? Acho que você deve conseguir remover o minificador de seus aplicativos package.json ...

Parece que isso está vindo de mudanças no formato do fio do brilho que está inchando um pouco os tamanhos do modelo. Em particular, fazer uma diferença no aplicativo é https://github.com/glimmerjs/glimmer-vm/blob/11cc83b2adf220bef298a1a6298c9e4e750c9fe1/packages/%40glimmer/interfaces/lib/compile/wire-format.d.ts#L76

@rwjblue - acredito que @krisselden está correto - isso não tem nada a ver com ember-hbs-minifier . Experimentei um aplicativo Ember totalmente novo com o seguinte auxiliar:

import Helper from '@ember/component/helper';
export default Helper.helper(() => true);

E dois componentes:

other-component.hbs

{{some-component foo=1}}

some-component.hbs

{{some-helper 1 2 3 @foo}}

3.16.3 produzido para os dois componentes:

other-component.hbs :

block: "{\"symbols\":[],\"statements\":[[1,[28,\"some-component\",null,[[\"foo\"],[1]]],false],[0,\"\\n\"]],\"hasEval\":false}",

some-component.hbs :

block: "{\"symbols\":[\"@foo\"],\"statements\":[[1,[28,\"some-helper\",[1,2,3,[23,1,[]]],null],false],[0,\"\\n\"]],\"hasEval\":false}",

O mesmo para 3.17:

other-component.hbs :

block: "{\"symbols\":[],\"statements\":[[1,0,0,0,[31,2,14,[27,[26,0,\"CallHead\"],[]],null,[[\"foo\"],[1]]]],[1,1,0,0,\"\\n\"]],\"hasEval\":false,\"upvars\":[\"some-component\"]}",

some-component.hbs :

block: "{\"symbols\":[\"@foo\"],\"statements\":[[1,0,0,0,[31,2,11,[27,[26,0,\"CallHead\"],[]],[1,2,3,[27,[24,1],[]]],null]],[1,1,0,0,\"\\n\"]],\"hasEval\":false,\"upvars\":[\"some-helper\"]}",

Eu não chamaria isso de "bug", simplesmente não é muito legal. Quanto maior for o aplicativo que você tem, maiores serão os modelos.

A mudança no formato do fio parece estar relacionada ao trabalho realizado aqui: https://github.com/glimmerjs/glimmer-vm/pull/972

https://github.com/glimmerjs/glimmer-vm/pull/1056

Ember 3.16

- dist/assets/ember-observer.js: 706.89 KB (66.89 KB gzipped)

Ember 3.17

 - dist/assets/ember-observer.js: 743.7 KB (69.63 KB gzipped)

Depois de const enum string to number

 - dist/assets/ember-observer.js: 739.58 KB (69.44 KB gzipped)

Removendo dados loc

 - dist/assets/ember-observer.js: 723.55 KB (68.06 KB gzipped)

Flatten Get + GetPath + GetContextualFree expressões

- dist/assets/ember-observer.js: 721.99 KB (68.04 KB gzipped)

Eu fiz um utilitário, se você não se importasse de executar em seus aplicativos, para me dizer como o patch se sai

https://www.npmjs.com/package/ember-template-size

$ npx ember-template-size .
npx: installed 11 in 1.766s
{
  '3.16.3': {
    version: '3.16.3',
    original: 793656,
    compiled: 1223295,
    brotli: 242598,
    gzip: 242606
  },
  '3.17.0-patched': {
    version: '3.17.0-patched',
    original: 793656,
    compiled: 1299096,
    brotli: 258803,
    gzip: 258826
  },
  '3.17.0': {
    version: '3.17.0',
    original: 793656,
    compiled: 1624741,
    brotli: 294760,
    gzip: 294780
  }
}

e para https://github.com/rust-lang/crates.io :

{
  '3.16.3': {
    version: '3.16.3',
    original: 73613,
    compiled: 143264,
    brotli: 32477,
    gzip: 32608
  },
  '3.17.0-patched': {
    version: '3.17.0-patched',
    original: 73613,
    compiled: 160526,
    brotli: 34663,
    gzip: 34803
  },
  '3.17.0': {
    version: '3.17.0',
    original: 73613,
    compiled: 183711,
    brotli: 36903,
    gzip: 37070
  }
}

para nós:

{
  '3.16.3': {
    version: '3.16.3',
    original: 281240,
    compiled: 450040,
    brotli: 98120,
    gzip: 98142
  },
  '3.17.0-patched': {
    version: '3.17.0-patched',
    original: 281240,
    compiled: 494042,
    brotli: 105152,
    gzip: 105178
  },
  '3.17.0': {
    version: '3.17.0',
    original: 281240,
    compiled: 596287,
    brotli: 117757,
    gzip: 117784
  }
}

O patch representa a maioria das ideias fáceis que tive. Tenho mais algumas ideias, mas com base nos resultados até agora, não vou recuperar o resto da regressão. O refatorador que causou a regressão era grande e permite alguma direção futura e eu tenho tempo limitado.

Tenho mais 2 ideias simples, achatar [Append, 1 | 0, ...] em [TrustingAppend | Append, ..] e então há uma tupla de formato de ligação que usa um sinalizador booleano que pode usar 1 | 0 em vez disso.

Para sua informação - https://github.com/emberjs/ember.js/pull/18941 aborda a maior parte do crescimento vs 3.16 (embora ainda maior em cerca de 3%, no qual estamos trabalhando).