因此,在我的應用程序中,用戶可以在某些div標籤內創建一些內容,並且每個內容或我稱之爲「元素」的元素都有自己的對象。目前我使用一個函數來計算原始的div標籤,該元素已經被放置在裏面使用jquery選擇器,但是我想在性能方面,只要存儲一個元素的引用到div標籤被創建,而不是稍後計算? 所以現在我用這樣的:性能問題:使用選擇器存儲對DOM元素的引用
$('.div[value='+divID+']')
,而是我可以存儲元素中的參考,當IM創造的元素。這對性能會更好嗎?
因此,在我的應用程序中,用戶可以在某些div標籤內創建一些內容,並且每個內容或我稱之爲「元素」的元素都有自己的對象。目前我使用一個函數來計算原始的div標籤,該元素已經被放置在裏面使用jquery選擇器,但是我想在性能方面,只要存儲一個元素的引用到div標籤被創建,而不是稍後計算? 所以現在我用這樣的:性能問題:使用選擇器存儲對DOM元素的引用
$('.div[value='+divID+']')
,而是我可以存儲元素中的參考,當IM創造的元素。這對性能會更好嗎?
如果你有很多這些綁定,最好存儲對它們的引用。正如在評論中提到的那樣,變量查找比在DOM中查找事情要快得多 - 特別是使用當前的方法。 jQuery選擇器比純DOM替代品慢,並且該特定選擇器將非常慢。
這是一個基於epascarello的測試,它顯示了jQuery,DOM2方法和引用之間的區別:http://jsperf.com/test-reference-vs-lookup/2。如預期的那樣,變量賦值速度非常快。另外,DOM方法也大大超出了jQuery。請注意,這是以雅虎的主頁爲例。
另一個考慮因素是DOM的大小和複雜性。隨着這種增加,參考緩存方法仍變得更加有利。
通過ID查找元素非常快。我不是100%確定我瞭解你的其他方法,但我懷疑它會比通過它的id對元素進行簡單查找更好,瀏覽器知道如何最好地執行此任務。從你所解釋的我看不出你的方法會更快。
我同意,如果他實際上是通過它的Id選擇元素。 – 2012-08-02 20:52:15
根據他發佈的代碼,他沒有通過ID查找它。 – Radu 2012-08-02 20:53:22
@Radu,所以問題得到了解答。他正在做的是按類和屬性值查找......呃,絕對不會比通過id查找更快。 – 2012-08-02 20:54:31
與每次查找本地變量相比,局部變量會超級快。 Test to prove it。
對'.html()'的調用是否在測試中用於任何目的?我會刪除它,因爲通常你想引用元素本身,所以你可以用它做更多的事情。 – Radu 2012-08-02 21:04:43
jQuery是一個構建和返回對象的函數。這部分並不是非常昂貴,但實際的DOM查找確實涉及到相當一部分工作。對於一個簡單的查詢來說,開銷並不高,比如像getElementById或getElementsByClassName這樣的現有DOM方法(IE8中不存在,所以它真的很慢),但是區別在於工作(構建一個包裝DOM訪問的對象方法),幾乎沒有工作(引用現有的對象)。如果您打算重用它們,請始終緩存選擇器結果。
此外,你正在使用的xpath的東西在某些瀏覽器中可能非常昂貴,所以是的,我肯定會緩存它。
東西注意:
在編寫選擇器時,請考慮需要多少標記來查看它。如果你知道你只想要一個特定ID的某個類的div,可以使用這些$('#theID div.someClass')中的一個,而不僅僅是$('div。SomeClass的);
但無論如何,只要避免工作的原則,如果您打算使用它兩次或更多次,請緩存該值。並儘可能避免重複請求DOM。
jQuery在這裏並不是真的很明顯。這是DOM查找,減慢了一切。 – 2012-08-02 21:07:07
感謝您的解釋:) – 2012-08-02 21:07:36
做DOM查找是建立該對象的過程的一部分,但是,這是昂貴的部分。在這方面編輯了我的帖子以獲取更多細節。 – 2012-08-02 21:07:57
是的,局部變量或屬性查找將遠遠快於創建jQuery對象並執行DOM選擇。 – 2012-08-02 20:53:00
...這有點令人困惑,因爲您似乎在應用程序中使用「元素」一詞來表示某些內容,而「標記」一詞指的是DOM元素。所以我並不完全關注你。 – 2012-08-02 20:54:25
@amnotiam是啊我明白你的意思... div「標記」看起來像這樣: