Opened 10 years ago
Closed 10 years ago
#9524 closed bug (cantfix)
Investigate performance tuning opportunities in prop()
Reported by: | Rick Waldron | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.next |
Component: | attributes | Version: | 1.6.1 |
Keywords: | prop perf | Cc: | |
Blocked by: | Blocking: |
Description
Using the following jsperf, we should investigate ways to improve the overall performance of prop() ( and possible is(), but that's another ticket altogether.)
http://jsperf.com/bens-test/7
Thanks to James Padolsey, Mathias Bynens and Kyle Simpson
Change History (4)
comment:1 Changed 10 years ago by
Component: | unfiled → attributes |
---|---|
Priority: | undecided → high |
comment:2 Changed 10 years ago by
comment:4 Changed 10 years ago by
Keywords: | prop perf added |
---|---|
Resolution: | → cantfix |
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
Did they give any ideas on how? It's not a very complicated function and the numbers honestly seem pretty good to me (with prop being the fastest of the ones that aren't simply getting the property). I don't really see prop as a replacement for using raw javascript in all situations, but it is at least convenient for setting on multiple elements and currently for retrieving a selected property that hasn't been set yet. In the example in the perf, it goes through jQuery.access (meaning you have all of the conveniences in signatures), which has 3 conditions then a call to prop. prop then has a condition for checking the elem and nodeType, 3 assignments depending on isXMLDoc, propFix and propHooks, a check if value is undefined, check if hooks exists, then return elem[ "checked" ]. None of that seems expendable to me.