Ember.js: Regression der Asset-Größe in Version 3.17.0

Kann in einem neuen Glutprojekt bestätigen:

__2.16.0__

• Hersteller: 692,58 KB (176,09 KB gzipped)
• App: 9,82 KB (2,15 KB gezippt)

__2.17.0__

• Hersteller: 715,12 KB (183,64 KB gezippt)
• App: 9,94 KB (2,2 KB gezippt)

Hat einige Anbieter diffs und es scheint von einigen Schimmer-vm - Updates, zB verursacht werden https://github.com/glimmerjs/glimmer-vm/commit/4c56c216465410f5bd6f4f53fb7d4508f8048f09#diff -64c3cabffb164d9a2c4bf2d427094e19 über https://github.com/emberjs/ ember.js / commit / 699439c0aaa1917754490efeb5751d10f77e5230

Hier gilt das gleiche.

2.16.3

• Anbieter: 886 KB (213 KB brotli)
• App: 1,01 MB (126 KB brotli)

2.17.0

• Anbieter: 907KB (219KB brotli)
• App: 1,15 MB (137 KB Brotli)

Außerdem habe ich bei unseren Integrationstests einen Leistungsabfall von ~ 5% von 2.16.3 auf 2.17.0 festgestellt.

PS @ Turbo87 - könnte es am HBS-Minifier liegen ? Ich benutze es auch. Könnte es für die neuen Vorlagen, die von der aktualisierten Glimmer-VM generiert wurden, irgendwie "kaputt" sein?

@ boris-petrov - Hast du etwas dagegen, das für uns zu überprüfen? Ich denke, Sie sollten in der Lage sein, den Minifier aus Ihren Apps zu entfernen package.json ...

Sieht so aus, als ob dies auf Änderungen im Schimmer-Drahtformat zurückzuführen ist, die die Vorlagengrößen ein wenig aufblähen. Ein Unterschied in der App ist insbesondere https://github.com/glimmerjs/glimmer-vm/blob/11cc83b2adf220bef298a1a6298c9e4e750c9fe1/packages/%40glimmer/interfaces/lib/compile/wire-format.d.ts#L76

@rwjblue - Ich glaube, @krisselden ist richtig - das hat nichts mit ember-hbs-minifier zu tun. Ich habe eine brandneue Ember-App mit folgendem Helfer ausprobiert:

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

Und zwei Komponenten:

other-component.hbs

{{some-component foo=1}}

some-component.hbs

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

3.16.3 hergestellt für die beiden Komponenten:

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

Gleiches gilt für 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\"]}",

Ich würde das nicht als "Bug" bezeichnen, es ist einfach nicht sehr schön. Je größer die App ist, desto größer werden die Vorlagen.

Die Änderung des Drahtformats scheint mit der hier geleisteten Arbeit zu tun zu haben: https://github.com/glimmerjs/glimmer-vm/pull/972

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

Glut 3.16

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

Glut 3.17

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

Nach const enum string to number

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

Lokdaten entfernen

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

Reduzieren Sie Get + GetPath + GetContextualFree-Ausdrücke

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

Ich habe ein Util gemacht, wenn es Ihnen nichts ausmacht, auf Ihren Apps zu laufen, um mir mitzuteilen, wie der Patch funktioniert

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

und für 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
  }
}

für uns:

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

Der Patch repräsentiert die meisten Ideen für niedrig hängende Früchte, die ich hatte. Ich habe noch ein paar Ideen, aber basierend auf den bisherigen Ergebnissen werde ich den Rest der Regression nicht wiederherstellen. Der Refaktor, der die Regression verursacht hat, war groß und ermöglicht eine zukünftige Ausrichtung, und ich habe nur begrenzte Zeit.

Ich habe 2 weitere einfache Ideen, abflachen [Anhängen, 1 | 0, ...] in [TrustingAppend | Anhängen, ..] und dann gibt es ein Drahtformat-Tupel, das ein boolesches Flag verwendet, das 1 | verwenden kann 0 stattdessen.

FYI - https://github.com/emberjs/ember.js/pull/18941 befasst sich mit dem Großteil des Wachstums gegenüber 3,16 (obwohl immer noch um ~ 3% größer, woran wir arbeiten).