Side navigation
#9524 closed bug (cantfix)
Opened June 06, 2011 02:39PM UTC
Closed June 07, 2011 11:39PM UTC
Investigate performance tuning opportunities in prop()
Reported by: | rwaldron | 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.)
Thanks to James Padolsey, Mathias Bynens and Kyle Simpson
Attachments (0)
Change History (4)
Changed June 06, 2011 02:40PM UTC by comment:1
component: | unfiled → attributes |
---|---|
priority: | undecided → high |
Changed June 07, 2011 12:06AM UTC by comment:2
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.
Changed June 07, 2011 12:08AM UTC by comment:3
I think that's all this was looking for.
Changed June 07, 2011 11:39PM UTC by comment:4
keywords: | → prop perf |
---|---|
resolution: | → cantfix |
status: | new → closed |