Ember.js: Régression de la taille des actifs dans la v3.17.0

Peut confirmer dans un nouveau projet de braise:

__2.16.0__

• fournisseur: 692,58 Ko (176,09 Ko compressé)
• app: 9,82 Ko (2,15 Ko compressé)

__2.17.0__

• fournisseur: 715,12 Ko (183,64 Ko gzippé)
• app: 9,94 Ko (2,2 Ko compressé)

Est-ce que certains diffs des fournisseurs , et il semble être causé par une lueur-vm mises à jour, par exemple https://github.com/glimmerjs/glimmer-vm/commit/4c56c216465410f5bd6f4f53fb7d4508f8048f09#diff -64c3cabffb164d9a2c4bf2d427094e19 via https://github.com/emberjs/ ember.js / commit / 699439c0aaa1917754490efeb5751d10f77e5230

Pareil ici.

2.16.3

• fournisseur: 886KB (213KB brotli)
• application: 1,01 Mo (126 Ko brotli)

2.17.0

• fournisseur: 907KB (219KB brotli)
• application: 1,15 Mo (137 Ko brotli)

De plus, j'ai remarqué une dégradation des performances d'environ 5% dans nos tests d'intégration passant de 2.16.3 à 2.17.0.

PS @ Turbo87 - minificateur HBS ? Je l'utilise également. Pourrait-il avoir "cassé" d'une manière ou d'une autre pour les nouveaux modèles générés par la VM Glimmer mise à jour?

@ boris-petrov - Ça vous dérange de vérifier ça pour nous? Je pense que vous devriez pouvoir supprimer le minifier de vos applications package.json ...

On dirait que cela vient de changements dans le format filaire scintillant qui gonfle un peu les tailles des modèles. En particulier, faire un diff sur l'application est https://github.com/glimmerjs/glimmer-vm/blob/11cc83b2adf220bef298a1a6298c9e4e750c9fe1/packages/%40glimmer/interfaces/lib/compile/wire-format.d.ts#L76

@rwjblue - Je crois que @krisselden est correct - cela n'a rien à voir avec ember-hbs-minifier . J'ai essayé une toute nouvelle application Ember avec l'aide suivante:

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

Et deux composants:

other-component.hbs

{{some-component foo=1}}

some-component.hbs

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

3.16.3 produit pour les deux composants:

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

Idem pour la version 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\"]}",

Je n'appellerais pas ça un "bug", ce n'est tout simplement pas très agréable. Plus l'application que vous avez est grande, plus les modèles seront volumineux.

Le changement de format de fil semble être lié au travail effectué ici: 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)

After const enum string to number

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

Suppression des données de localisation

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

Aplatir les expressions Get + GetPath + GetContextualFree

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

J'ai créé un utilitaire, si cela ne vous dérange pas d'exécuter vos applications pour me dire comment fonctionne le correctif

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

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

pour nous:

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

Le patch représente la plupart des idées de fruits à portée de main que j'avais. J'ai encore quelques idées, mais sur la base des résultats obtenus jusqu'à présent, je ne vais pas récupérer le reste de la régression. Le refactor qui a causé la régression était important et permet une orientation future et je dispose de peu de temps.

J'ai 2 idées plus simples, aplatir [Append, 1 | 0, ...] dans [TrustingAppend | Ajouter, ..] et puis il y a un tuple de format filaire qui utilise un indicateur booléen qui peut utiliser 1 | 0 à la place.

FYI - https://github.com/emberjs/ember.js/pull/18941 répond à l'essentiel de la croissance contre 3,16 (bien que toujours plus importante d'environ 3%, sur laquelle nous travaillons).