3

私は当然、競合他社と比較して Ember の優れた API/設計/構文に惹かれましたが、パフォーマンスが大幅に低下したことを見て非常に悲しくなりました。(たとえば、現在よく知られているhttp://jsfiddle.net/samdelagarza/ntMdB/167/を参照してください。) 私の目では、Chrome のバックボーンよりも少なくとも 4 倍遅いことがわかります。

EmberJS のバージョン 0.9.6 には、特にバインディングとレンダリングに関する多くのパフォーマンス修正が含まれているようです。ただし、このバージョンの Ember を使用すると、上記のベンチマークのパフォーマンスは依然として低下します。

上記のベンチマークは、1 つのフレームワークのバインディング コストを示すものだと思います。私は、バインディングが十分に機能する Flex から来たので、使用したいレンダラーごとにこれらの 5 つのバインディング (おそらく 20 のレンダラーを乗算) がオーバーヘッドになりすぎないかどうかを常に考える必要はありません。使いやすさは素晴らしいですが、十分なパフォーマンスが維持されている場合に限ります. (HTML5 はモバイルもターゲットにすることが多いため、なおさらです)。

現状では、Ember の美しさは、いくつかの競合他社と比較して、パフォーマンスの低下に見合うものではないと考える傾向があります。ここでは、多くのバインディングを持つ大きなアプリについて話しているためです。そうでなければ、そもそもそのようなフレームワークは必要ありません。 . 私は、Ember のパフォーマンスがわずかに低下しても問題ありませんでした。結局のところ、それはテーブルにより多くをもたらします。

したがって、私の質問はかなり一般的でオープンです。

  • ベンチマークの Ember 部分は、本物の問題を示すのに十分なほどよく書かれていますか?
  • 0.9.6 のパフォーマンス アップデートは非常に控えめなものでしょうか?
  • 主な貢献者によって特定された悪いパフォーマンスの領域はありますか?
4

1 に答える 1

7

これは実際にはバインディングが遅いという問題ではありませんが、必要以上に DOM の更新を行っています。私たちはこの特定の問題についていくつかの調査を行っており、これらの複数の操作を 1 つにまとめる方法についていくつかのアイデアを持っているため、これは将来的に改善されると期待しています.

とはいえ、これが現実的なベンチマークであるとは思えません。Ember (または Backbone) で重いアニメーションを行うことは決してお勧めしません。標準的なアプリ開発では、その頻度で多くの異なるビューを同時に更新する必要はありません。

通常のアプリで遅い領域を指摘していただければ、喜んで調査させていただきます。パフォーマンスは私たちにとって大きな関心事であり、通常の操作中に物事が本当に遅い場合は、それをバグと見なします. しかし、私が言ったように、パフォーマンス バインディング主導のアニメーションは私たちの目標の 1 つではありません。Ember は通常、他のライブラリとうまく連携するため、アニメーション ライブラリをプラグインして、Ember の外部でアニメーションを実行できるはずです。

于 2012-04-07T21:46:01.193 に答える