Skip to main content

Bug Tracker

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.)

http://jsperf.com/bens-test/7

Thanks to James Padolsey, Mathias Bynens and Kyle Simpson

Attachments (0)
Change History (4)

Changed June 06, 2011 02:40PM UTC by rwaldron comment:1

component: unfiledattributes
priority: undecidedhigh

Changed June 07, 2011 12:06AM UTC by timmywil 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 rwaldron comment:3

I think that's all this was looking for.

Changed June 07, 2011 11:39PM UTC by timmywil comment:4

keywords: → prop perf
resolution: → cantfix
status: newclosed