Ember.js: Regresión del tamaño de los activos en v3.17.0

Puede confirmar en un nuevo proyecto de brasas:

__2.16.0__

• proveedor: 692,58 KB (176,09 KB comprimido)
• aplicación: 9.82 KB (2.15 KB comprimido en gzip)

__2.17.0__

• proveedor: 715,12 KB (183,64 KB comprimido en gzip)
• aplicación: 9,94 KB (2,2 KB comprimido en gzip)

Hizo algunas diferenciaciones proveedores y parece que es causada por algún rayo-vm actualizaciones, por ejemplo https://github.com/glimmerjs/glimmer-vm/commit/4c56c216465410f5bd6f4f53fb7d4508f8048f09#diff -64c3cabffb164d9a2c4bf2d427094e19 través https://github.com/emberjs/ ember.js / commit / 699439c0aaa1917754490efeb5751d10f77e5230

Igual que aquí.

2.16.3

• Proveedor: 886KB (213KB brotli)
• aplicación: 1.01MB (126KB brotli)

2.17.0

• Proveedor: 907KB (219KB brotli)
• aplicación: 1,15 MB (137 KB brotli)

Además, noté una degradación del rendimiento de ~ 5% en nuestras pruebas de integración al pasar de 2.16.3 a 2.17.0.

PS @ Turbo87 : ¿podría ser por el minificador HBS ? También lo estoy usando. ¿Podría haberse "roto" de alguna manera para las nuevas plantillas generadas por la Glimmer VM actualizada?

@ boris-petrov - ¿Te importaría comprobarlo por nosotros? Creo que debería poder eliminar el minificador de sus aplicaciones package.json ...

Parece que esto se debe a cambios en el formato de cable brillante que aumenta un poco el tamaño de las plantillas. En particular, hacer una diferencia en la aplicación es https://github.com/glimmerjs/glimmer-vm/blob/11cc83b2adf220bef298a1a6298c9e4e750c9fe1/packages/%40glimmer/interfaces/lib/compile/wire-format.d.ts#L76

@rwjblue - Creo que @krisselden es correcto - esto no tiene nada que ver con ember-hbs-minifier . Probé una nueva aplicación Ember con el siguiente ayudante:

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

Y dos componentes:

other-component.hbs

{{some-component foo=1}}

some-component.hbs

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

3.16.3 producido para los dos 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}",

Lo mismo 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\"]}",

Yo no llamaría a eso un "error", simplemente no es muy agradable. Cuanto más grande sea la aplicación que tengas, más grandes serán las plantillas.

El cambio en el formato de cable parece estar relacionado con el trabajo realizado aquí: 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)

Después de la cadena de enumeración constante al número

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

Eliminar datos de locomotoras

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

Aplanar expresiones Get + GetPath + GetContextualFree

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

Hice una utilidad, si no le importaría ejecutar sus aplicaciones, hágame saber cómo funciona el parche

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
  }
}

y 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 nosotros:

{
  '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
  }
}

El parche representa la mayoría de las ideas de frutas fáciles de conseguir que tenía. Tengo un par de ideas más, pero basándome en los resultados hasta ahora, no voy a recuperar el resto de la regresión. El refactor que causó la regresión fue grande y permite alguna dirección futura y tengo un tiempo limitado.

Tengo 2 ideas más simples, aplana [Append, 1 | 0, ...] en [TrustingAppend | Append, ..] y luego está la tupla de formato de cable que usa una bandera booleana que puede usar 1 | 0 en su lugar.

FYI: https://github.com/emberjs/ember.js/pull/18941 aborda la mayor parte del crecimiento frente a 3.16 (aunque aún mayor en ~ 3%, en el que estamos trabajando).