我們使用EmberJS（版本1.0.0-rc5）創建了一個Web應用程序。我們注意到Chrome的出色表現，不幸的是我們必須支持Internet Explorer 7作爲我們的主要平臺。Ember.js在IE 7中渲染緩慢
我們注意到在IE7上的性能很糟糕。在調查問題後，歸結爲模板的渲染（儘管路由也非常慢）。如果這是由於我們構建應用程序時出現錯誤，或者這是Ember的問題，我們不知道。
我創建了一個小樣本應用程序來重現問題。你可以在http://manoswerts.be/playground/ember-performance找到它。它呈現出與我們在應用中所做的相似的樹。在Chrome中運行時，結果會立即顯示。在IE7中，渲染需要30秒到1分鐘的時間。在IE8中，「僅」需要7秒。
有人熟悉這個嗎？有沒有解決這個問題的方法？
任何幫助，非常感謝。
嘗試添加以下，以獲取有關這麼久什麼是採取一些更細節：
Ember.subscribe('render', {
before: function(name, start, payload){
return start;
},
after: function(name, end, payload, start){
var duration = Math.round(end - start);
var template = payload.template || '';
//console.log(Ember.inspect(payload));
//var title;
var view = payload.object.toString();
console.log('rendered', template, view, 'took', duration, 'ms');
}
});
這將給你呈現的每個視圖時機。當我在Chrome中運行您的示例時，每個人模板都需要大約2ms才能呈現。還有一些開銷與嵌套的{{each}}幫助程序有關，並在這些{{each}}塊中呈現「虛擬」視圖。列表渲染時間總共爲104毫秒。總時間將是在您點擊Show results按鈕後寫入的最後一個console.log行。
因此，根據你所說的話，我預計總時間會比ie7和ie8慢一個數量級。如果是這樣的話，想知道這是平均分配還是有一個特定的視圖呈現得慢得多。
感謝您的提示。我會試試看看輸出是否能夠啓發我。我忘記提到在本地Handlebars（不通過Ember）中嵌套{{each}}塊的渲染看起來非常快。最重要的是，這些觀點還增加了開銷，這使得它不可接受。我會通知你測試的結果。 –
快速更新：我們突然得到綠燈，將IE 8用作我們的目標瀏覽器。所以目前這不再是我們的問題。不過，我會盡量在業餘時間給@Mike Grassotti調查他的調查方法。 –
我不知道Ember是如何工作的，但它看起來像是在每個li元素上添加一個事件偵聽器。這是自願的嗎？你不能使用事件代表團嗎？ –
盡我們最大的尊重，「我們必須支持IE7」有多強大。這是因爲你的用戶實際上仍然停留在IE7上，還是僅僅因爲有人決定將它指定爲支持的基準？我的觀點是，在過去的12個月裏，IE7的使用已經下降了。實際上幾乎沒有人還在使用它;當然不是自願的。如果可能的話，我的建議是放棄IE7的支持，因爲是的，它吸引人，而且它確實有很糟糕的表現。但最重要的是，因爲你會做所有的工作，而且沒有人會真正在IE7中使用它。真是浪費。 – Spudley
這是一個問題，無論IE7的支持，因爲它是200毫秒鉻上渲染80項，或者它只是我嗎？ Core i5在這裏。 – Esailija