Jquery/Javascript的速度......我應該真的在意嗎？

我見過很多帖子比較各種選擇器查詢和DOM遍歷方法的速度。當然，在數百或數千個元素以及O^n操作的情況下，它很重要，但在99％的情況下，速度真的很重要，因爲Jquery在響應用戶操作時執行一些DOM操作（或炫耀動畫，或烤麪包）？Jquery/Javascript的速度......我應該真的在意嗎？

幾乎所有的JQuery動作都不比往返服務器更快嗎？

設計優化的服務器端代碼是有意義的。而且它對內存分配負責，並在JavaScript中進行清理是非常有意義的，所以用戶的瀏覽器不會像Flash大約v5那樣運行。我認爲在浪費時間優化JQuery/Javascript的速度方面沒有任何意義，除非在測試過程中明顯降低了頁面的速度。

有人能告訴我是否和爲什麼我應該開始關心JQuery速度嗎？

編輯

我的語氣是公認愛發牢騷，但並不意味着是議論文。上有如何很好的資源，當你需要here，更好的方式來問我的問題已經接近優化：

什麼是次優的Javascript/jQuery的影響？
如果我沒有注意到它，我應該擔心它嗎？

接受

閱讀的答覆後，我認爲最好這個問題的答案取決於你的項目和團隊規模。在情況下程序員不必頁面，用戶將看到的完整視圖，如團隊中

程序員負責各個功能頁面
程序員開發獨立的單元測試
上有一個定製的前端API或其他代碼可能影響實際響應時間

然後它是有道理的更謹慎和'過早優化'作爲例行公事。如果有專業的，專業的前端設計人員無所作爲，這是可行的。

小項目，比如我現在兩個人的團隊：

缺乏專業化
需要高程序員輸出
在一個整個前端濃責任人

優先列表中的所有優化優化。 @ Anurag的回答幫助我找到了問題的核心，並做出了最佳決策。

來源

2011-03-02 RSG

事實上，優化任何東西prematurely，而不僅僅是jQuery。

加入這些微優化所耗費的時間和精力可能不值得收益。如果某些事情明顯緩慢，那麼可以深入研究這個問題，但是另外要專注於設計應用程序。創建好的應用程序並不是一件容易的事情，而嘗試過早優化通常會導致維護設計和架構變得複雜而困難。

來源

2011-03-02 07:29:54 Anurag

我其實想要投票結束問題主觀和議論，但我想這不是關於beeing議論。

我們應該問這裏的問題是，爲什麼我們不應該優化我們的代碼？

我不得不承認，ECMA-/Javascript解釋器在過去幾年確實有很大的提高，所以整體的Javascript性能提高了。但是，瀏覽器環境中的Javascript仍然不是很快。特別是當涉及到DOM操作它實際上很慢（或者：它可能真的很慢）。

有很多關於這個話題的優秀書籍，我強烈推薦的是Nicholas C. Zakas的高性能Javascript。

僅舉幾個原因，爲什麼我們要優化我們的代碼是：

並非所有用戶都有一個新銳瀏覽器，我們應保證用戶使用老又慢的瀏覽器也有很好的用戶體驗
Javascript一般來說，仍然有侷限性。這意味着內存的使用是有限的，並且執行時間爲
Javascript &瀏覽器UI線程無法並行執行。這意味着緩慢Javascript會影響用戶體驗
畢竟這是一個很好的做法！如果您習慣於編寫最佳代碼，那麼您每次都會這樣做，我認爲這是件好事

即使有像jQuery這樣高度抽象的框架，您也可以輕鬆做出可怕的事情。舉個例子，一個簡單的查詢語句就像

$('body > *')

幾乎總是非常慢。問題是，即使這個聲明不會顯着減慢速度，但如果你沒有意識到這一點，並且你沒有優化就編寫了所有的代碼，它最終會加起來。

來源

2011-03-02 07:27:55 jAndy

你應該在乎什麼時候開始重要。

也就是說，性能應該是您的應用程序的特定要求，並且與任何應用程序一樣，您不應該花太多時間擔心性能，直到缺乏影響某些要求爲止。當然，如果有一個簡單的線性替代方案，我並不是說使用O(n^3)算法，但是在許多地方都會出現瓶頸問題，而您選擇的JavaScript庫只是其中之一。

來源

2011-03-02 07:32:44 maerics

jQuery可以幫助您專注於開發，而不用花費數小時來解決跨瀏覽器的不兼容問題。速度不是問題，至少不是肉眼。這一切歸結爲您的代碼是如何編寫和優化的。這並不意味着您將停止使用javaScript，而是針對ajax請求等任務，使用jQuery可以讓生活更輕鬆，而不必擔心跨瀏覽器的不兼容問題。

UPDATE 閱讀下面的評論。這是我用來測試javascript的for vs jQuery的$.each函數。 jQuery本地贏得了4ms。 jQuery 11ms vs javaScript 14ms

var array = new Array(); 
for (var i = 0; i < 10000; i++) { 
    array[i] = 0; 
} 

console.time('native'); 
var l = array.length; 
for (var i = 0; i < l; i++) { 
    array[i] = i; 
} 
console.timeEnd('native'); 

console.time('jquery'); 
$.each(array, 
function(i) { 
    array[i] = i; 
}); 
console.timeEnd('jquery');

來源

2011-03-02 07:40:16 Hussein

在UI上下文中2到160毫秒響應時間之間的差異可以忽略IMO。這是用JSLitmus完成的嗎？ – RSG

@RSG你是對的，你應該只在出現問題時進行優化。然而，160毫秒的響應將其放在人類感知的範圍上。如果您的用戶界面至少需要160ms *，那麼您需要考慮優化或向用戶提供「做某事」的反饋。 – johnhunter

我發佈的圖表結果不正確。我使用console.time來循環，我的語法影響了結果。我更新了我的帖子，請參閱上面用於測試的代碼。再次嘗試之後，它顯示jQuery的'.each'比javaScript native'for'快。 – Hussein

如果你的代碼很慢，jQuery不會是瓶頸。它的功能很快。

更可能的是，你的算法將成爲問題。

來源

2011-03-02 07:55:55

Jquery/Javascript的速度......我應該真的在意嗎？

回答

相關問題