グリマーバイナリ実験

Glimmerのバイナリコード実験に関する記事の翻訳、共著者：Sarah Clatterbuck、Chad Hietala、Tom Dale。



1年ほど前、 Ember.jsには大きな変更が加えられました。 LinkedInのエンジニアとオープンソースコミュニティの緊密な協力により、Emberのレンダラーエンジンを新しいライブラリGlimmer VMに置き換えました。これにより、パフォーマンスが向上し、コンパイルされたテンプレートのサイズが大幅に削減されました。



GlimmerはHandlebarsテンプレートを関数型プログラミング言語と呼び、ブラウザーで実行できる一連の命令にコンパイルします。 これらの命令、またはオペコード（おおよそのトランスレーターオペレーションコード）は、JSONの形式でコンパクトなデータ構造にエンコードされます。



linkedin.com WebアプリケーションをGlimmerに移行すると、ダウンロード時間が大幅に改善されました。 ファイルサイズを40％削減することに加えて、JSONでテンプレートをコンパイルすることにより、ブラウザーがJavaScriptの解析に費やす時間も削減しました。 さらに、この変更により、ケースの90％で読み込み時間が1秒以上改善されました。



この記事では、コンパイルされたテンプレートを解析するのに必要な時間を完全になくすことでロード時間をさらに改善するための最近の実験について説明します。

Glimmer.jsを使用した実験の開示

約6か月前、Ember.jsチームはGlimmer.jsのリリースを個別のコンポーネントライブラリとして発表しました。 プレゼンテーションレイヤーを分離することで、EmberとGlimmerの仮想マシンを最大限に活用し、新興市場向けのモバイルアプリケーションやSEOページなどの軽量製品を作成する開発者に引き継ぐことができました。



Glimmerのブレークスルーにより、私たちのチームは次の月に多くの実験を行うことができました。

たとえば、最近、私たちはハイブリッドレンダーを提示しました。このレンダーでは、htmlがサーバーで生成され、ブラウザーで再水和されます（こちらの翻訳者のメモを参照 ）。 これは、Glimmer仮想マシンアーキテクチャによって提供されるパフォーマンス上の利点のほんの始まりに過ぎません。



Web生産性の聖杯は、ユーザーがアクションを実行したときにすばやく起動し、すぐに更新し（60 fpsのパフォーマンスを維持する）、デフォルトのパフォーマンスを提供することです。 。



従来、インスタントダウンロードを実行するために最小限のJavaScriptコードを提供することと、複雑なレスポンシブUIを使用する能力との間にはジレンマがあります。 基本的なトレードオフは、アプリケーションが成長するにつれて生産性と生産性が低下することです。 Glimmerの目標は、軽量で高速かつ生産的なアプリケーションを作成することです。 この目標を達成するための鍵の1つは、アプリケーションに追加される各新しいコンポーネントのコストを削減することです。

インスタントテンプレート

JavaScriptからJSONに切り替えると、コンパイルされたテンプレートの解析コストが削減され、Glimmerを高度なブラウザー機能と組み合わせて解析ステップを完全に排除しました。



ダウンロード時間を最適化する場合、ほとんどの開発者はダウンロードを高速化するためにファイルサイズを小さくしようとします。 ただし、JavaScriptベースのアプリケーションでは、ブラウザーがコードを分析、コンパイル、評価する機能も起動のパフォーマンスに影響します。 モバイルデバイスでは、JavaScriptコードの分析とコンパイルがデスクトップコンピューターの2〜5倍遅いため、これは重要です。 これだけ、唯一のステップはアプリケーションの全体的なパフォーマンスに大きく影響します。



今日、ほとんどのフレームワークはビュー（ビュー）をJavaScript関数にコンパイルします。 そのようなJavaScriptコードの解析コストはしばしば隠され、新しい機能が追加されると、アプリケーションの実行はますます遅くなります。



前述のとおり、Glimmerはパターンを一連のオペコードにコンパイルし、JSONとしてブラウザーに渡します。 JSON文法はJavaScript文法よりもはるかに単純であるため、同じデータを解析する場合、JSONパーサーはJavaScriptパーサーよりも10倍速く動作できます。



しかし、これはすべて同じですが、テンプレートのサイズが大きくなると解析時間は長くなりますが、すでに遅くなっています。 解析ステップを回避できたらどうでしょうか？

近年、ブラウザはバイナリデータを完全に処理することを学びました。 ArrayBufferなどの低レベルAPIを使用すると、JavaScriptプログラムはネイティブデータと同等の速度でバイナリデータを処理できます。 これを利用して、Glimmer仮想マシンが直接実行できる独自のバイトコード形式にテンプレートをコンパイルしました。 JVMバイトコード形式と同様に、Glimmerバイトコードはプラットフォームに依存しないバイナリ形式であり、Glimmer仮想マシンの一連の命令をオペコードとその演算子のバイトストリームにエンコードします。 JSONまたはJavaScriptの解析のパフォーマンスに依存する代わりに、ブラウザーからネットワークから生のバイトをコピーする機能によってのみ制限されるようになりました。

Glimmerバイトコードエンコーディング

多くの仮想マシンと同様に、Glimmer仮想マシンの指示は数字で認識されます。 バイトコードは、これらの数字のコード化されたシーケンスです。 Glimmerの独自性は、そのコマンドセットがブラウザーでDOMをレンダリングするように設計されているという事実にあります。



たとえば、テンプレート

 <h1>Hello World</h1>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビルド時に次のJSON形式にコンパイルされます。

 [ ["open-element", "h1", []], ["text", "Hello World"], ["close-element"] ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザで、JSON形式をコンパイルする最後のステップで、数字の配列に変換します。各数字はオペレーションコードまたはオペランドです。

 const Program = [25, 1, 0, 0, 22, 2, 0, 0, 32, 0, 0, 0];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JSONの文字列が整数に置き換えられていることに注意してください。 これは、いわゆる「文字列インターン」技術を使用し、同一行の重複を排除するためです。ここでは、文字列は文字列定数のプール内のオフセットに置き換えられ、実際にはファイルサイズを大幅に削減します（文字列定数divを何回繰り返すかを想像してください）テンプレート）。



最初に、バイトコードは各操作を4つの32ビット整数としてエンコードしました。最初の32ビットの数字は操作の種類（オペコード）を表し、残りの96ビットは最大3つの命令引数（オペランド）を表します。



このアプローチはコードの実行に効果的であるという事実にもかかわらず、マイナスがあります-バイトコードを持つファイルのサイズは必要以上に大きくなります。 これは、ほとんどの命令がオペランドを必要としないか、1つのオペランドのみを受け入れるにもかかわらず、常に3つのオペランド用にスペースを確保しているためです。 したがって、プログラムは空のバイトでいっぱいになりますが、空のバイトは存在しないはずです。 さらに、Glimmer命令セットには80個のオペコードしか含まれていないため、オペコードの予約スペースを8ビットに減らすことができます。



最終的に、よりコンパクトなコーディングスキームに決定しましたが、これはまだ16ビットでした。 最初の8ビットはオペコードで、次の2ビットはオペランドの数をエンコードするために使用され、最後の6ビットは将来の使用のために予約されています。 各オペランドは、もしあれば、追加の16ビットでエンコードされます。



このエンコードスキームでは、各命令は2〜6バイトを使用でき、次のようになります。

 /* Fixed Opcode */ /* Operand? */ /* Operand? */ /* Operand? */ [0bIIIIIIIILLRRRRRR, 0bAAAAAAAAAAAAAAAA, 0bAAAAAAAAAAAAAAAA, 0bAAAAAAAAAAAAAAAA] /* I = instruction (opcode) type L = operand length R = reserved A = operand value */ view raw
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この新しいスキームにより、コンパイルされたプログラムのサイズが50％削減されます。 この回路のデコードには、ビットをマスクしてシフトし、オペコードの長さとオペランドの長さを見つけるだけなので、小さなオーバーヘッドがあります。

バイトコードとJavaScriptのギャップを埋める

遭遇した問題の1つは、コンパイルフェーズ全体をプロジェクトビルダーに移行することでした。 前に、アプリケーションのJavaScriptコードが読み込まれるとすぐに、ブラウザーでテンプレートをコンパイルする最後の手順を実行しました。 これにより、コンパイルされたテンプレートを、ユーザーアクションを処理するコンポーネントクラスなどのJavaScriptオブジェクトに接続できました。



最初のステップは、Node.jsですべてのレベルのコンパイルを提供することでした。 「バンドルコンパイラ」と呼ばれる新しいインターフェイスを作成しました。これは、すべてのコンパイルレベルを単一のAPIにカプセル化し、アセンブリツールが「バンドル」テンプレートをバイトコードに変換できるようにしました。



次に、追加の問題に直面しました。バイトコードにコンパイルするとき、実行時にこのバイトコードを正しいJavaScriptオブジェクトに「接続」する方法は何ですか？ この問題を解決するために、「ハンドル」（ハンドラー）の概念を導入しました。 ハンドラーは、コンポーネントやヘルパーなど、テンプレート内の外部オブジェクトに関連付けられた一意の数値識別子です。 コンパイル時に、各外部オブジェクトをバイトコードでエンコードされたハンドラーに関連付けます。 たとえば、 <UserProfile />コンポーネントの呼び出しが見つかった場合、それを識別子42のハンドラーに関連付けることができます（41の一意のコンポーネントが既に呼び出されていると仮定します）。



このようなコンポーネントを呼び出すと、Glimmer命令セットのいくつかのオペコードにコンパイルされます。 これらの命令の1つは、JavaScriptコンポーネントクラスを仮想マシン（VM）スタックにプッシュする0x003b PushComponentDefinitionです。 バイトコードにコンパイルされると、この命令は4バイト0x00 0x3b 0x01 0x2Aを作成します。 最初の2バイトは、 PushComponentDefinitionオペコードをエンコードします。 2番目の2バイトはオペランド（この場合はハンドラー（番号42））をエンコードします。



それでは、ブラウザでバイトコードを実行するとどうなりますか？ 整数42を生き生きとしたJavaScriptクラスに変換する方法は？ このトリックを「外部モジュールテーブル」と呼びます。 これは、生成されたJavaScriptコードの小さな断片であり、2つの世界を組み合わせて、ハンドラーを対応するJavaScriptクラスに効率的にマップできるデータ構造を定義します。



この例では、 UserProfileを42ハンドラーに関連付けたため、外部モジュールテーブルは配列であり、 UserProfileクラスは配列内の42個の要素です。

 import UserProfile from './src/ui/components/UserProfile/component'; /* ...other component imports */ export let table = [ /* Component1 */, /* Component2 */, /* ... */, /* Component41 */, UserProfile, /* Component43 */, /* ... */ ];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バイトコードの実行中に、「リゾルバー」と呼ばれるヘルパーオブジェクトがハンドラーを適切なJavaScriptオブジェクトに変換します。 各ハンドラーは配列内のオフセットでもあるため、このコードは簡単で高速です。

 resolve<U>(handle: number): U { return this.table[handle]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.gbx形式（Glimmer Binary Experience）でプロジェクトをビルドし、ブラウザーに転送して、ブラウザーでヘッダーをレンダリングします。

次は何ですか

バイトコードコンパイラを内部アプリケーションに統合するだけで、Glimmer.jsの概念を証明し、すぐに本番アプリケーションで実際の結果を収集できることを楽しみにしています。 これは、さまざまなハードウェア、オペレーティングシステム、ブラウザ、および帯域幅の組み合わせに対するさまざまなアクターを使用して、現実世界におけるこれらの変更の影響を評価するのに役立ちます。



Glimmerバイトコードはファイルサイズを削減し、最後のステップの解析とコンパイルのコストを完全に排除するため、特にCPUがボトルネックとなるハードウェア機能の低いデバイスでは、アプリケーションの起動時間の大幅な改善が期待されます。 さらに重要なことは、明確に定義されたバイナリ形式の方向に仮想マシンのファイル形式と内部要素を調整するプロセスは、将来的に多くの興味深い実験を開くことになります。 特に、選択したバイトコード形式は、Glimmer仮想マシンの一部をWebAssemblyテクノロジーに向けて調査および変更し、解析コストを削減し、実行時のパフォーマンスをさらに向上させることができるという意味です。



LinkedInの私たち全員がオープンソースの大ファンであり、上記のすべての作業はGitHubで公開されていました。 Glimmerプロジェクトに興味がある場合は、GitHubのGlimmer VMおよびGlimmer.jsリポジトリに招待します。

謝辞

LinkedInでバイトコードの編集に携わったChad HietalaとTom Daleに感謝します。 さらに、オープンソースコミュニティでこのビジョンを実現するために協力してくれたYehuda KatsuとGodfrey Chenに感謝します。