出于性能原因不使用ember-data是一个好主意

Question

以下是Ember对象创建的几个性能测试。

Ember v2.3.1 with jQuery

Ember v2.16.0（截至本文撰写时的最新内容）

一些外卖：

1. 创建Ember对象比创建普通JS对象慢得多（Ember v2.3.1慢大约100倍，Ember v2.16.0慢大约300倍）
2. Ember v2.16.0在Ember对象创建方面比Ember v2.3.1慢

我反复进行了性能测试。在我的所有运行中，上述两点是一致的。

现在，假设我想使用Ember创建一个新的复杂Web UI。 UI需要频繁地与后端交换相当数量的数据（例如，每个http调用100KB）。基于以上性能结果，以及我假设ember-data需要为每个模型调用多个Ember.Object.create()，在应用程序中不使用ember-data是一个好主意？一种替代方法是手动在模型钩子中进行ajax调用，只在必要时创建Ember对象？

顺便说一下，我们假设在这种情况下我们必须使用Ember。这里有趣的问题是我们是否可以通过不使用余烬数据来获得性能提升？或者，如果我们需要使用ember-data来获得它的优势，那么我们可以做的常规优化是什么？

Answer 1

  

基于以上的性能结果，以及我假设ember-data需要为每个模型调用多个Ember.Object.create（），在应用程序中不使用ember-data是一个好主意？一种替代方法是手动在模型钩子中进行ajax调用，只在必要时创建Ember对象？

绝对值得问这个问题。 Ember Data是否为您提供了使用所需的物品？

  顺便说一下，我们假设在这种情况下我们必须使用Ember。这里有趣的问题是我们是否可以通过不使用余烬数据来获得性能提升？或者，如果我们需要使用ember-data来获得它的优势，那么我们可以做的常规优化是什么？

我希望你能够在没有ember-data的情况下获得更好的性能，因为它有许多移动部件。一些核心团队（以及LinkedIn的人员）对如何降低Ember Data的大小和复杂性有各种想法和梦想，但目前并不是他们的主要关注点。作为降低复杂性的工作的一部分，Ember Data 2.13中的一些更改导致了一些错误。您是否在ED 2.12上看到了相同的性能特征差异？

Re：通常的优化，我所知道的，可能值得在#-dev-ember-data Slack频道上询问。如果您有时间/兴趣，目前缺乏专门的Ember Data人员，并且有兴趣帮助提高性能对整个社区都有好处