Bug Tracker

Opened 12 years ago

Closed 12 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:


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

Change History (4)

comment:1 Changed 12 years ago by Rick Waldron

Component: unfiledattributes
Priority: undecidedhigh

comment:2 Changed 12 years ago by timmywil

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.

comment:3 Changed 12 years ago by Rick Waldron

I think that's all this was looking for.

comment:4 Changed 12 years ago by timmywil

Keywords: prop perf added
Resolution: cantfix
Status: newclosed
Note: See TracTickets for help on using tickets.