2013-02-08 64 views
0

看來,爲我的模型獲取元數據在Chrome中非常緩慢,但在IE中速度很快。在Chrome瀏覽器中獲取微風元數據速度很慢,在IE中速度很快

我的dbcontext包含大約35個具有大量導航屬性的實體,我添加的每個實體都會增加延遲。目前延遲大約爲20秒,從查詢返回原始元數據開始,並且完全是工作頻繁的CPU,內存使用保持穩定。我有一個i7處理器和充足的內存。

我知道JavaScript引擎在這兩種瀏覽器中的設計方式存在差異,Chrome JIT編譯器針對浮點操作進行了優化(這就是爲什麼webgl圖形比IE瀏覽器快1000倍) - 這可能會影響fetchMetaData必須完成的工作嗎?

有沒有其他人注意到這種緩慢?難道我的關係錯了嗎?一旦延遲結束,所有事情都會奏效,所以我懷疑這種關係可能是一個問題。

+0

通過最新版本的方式測試 – Dimitri 2013-02-08 16:56:07

回答

1

發現問題和解決方案!

感謝您抽出寶貴時間來看看這個問題,在您回覆之後,我決定將整個項目分解爲基礎知識,以便我可以重現問題並尋找任何干擾。

這是一個我已經實現Breeze的較老的項目。該項目使用了標準的jQuery後/ get方法得到MVC的數據,因爲日期和時間發佈,並從MVC接收JSON數據時一直是一個問題,我在我的啓動腳本中有這樣的代碼:

// Add datafilter to jQuery ajax calls to translate dates 
$.ajaxSettings.dataFilter = function (data, type) { 
    //if (type === 'json') { 
    // convert things that look like Dates into a UTC Date string and completely replace them. 
    data = data.replace(/(.*?")(\\\/Date\([0-9\-]+\)\\\/)(")/g, 
        function (fullMatch, $1, $2, $3) { 
         try { 
          return $1 + new Date(parseInt($2.substr(7))) + $3; 
         } 
         catch (e) { } 
         // something miserable happened, just return the original string 
         return $1 + $2 + $3; 
        }); 
    //} 
    return data; 
}; 

後刪除這段代碼(因爲breeze的日期是正確的),一切正常。這種類型的代碼在其他需要處理日期的較老項目中可能很常見,我知道我從WiredPrairie得到了上述代碼,我相信其他人也會遇到這個問題。

+0

很高興你找到它,並感謝您發佈有關它。 :) – 2013-02-10 05:33:38

0

德米特里, 我不能repro這個,所以我想知道是否沒有其他涉及。你是否也嘗試過Firefox?

相關問題