Ticket #9524 (closed bug: cantfix)
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: | |
| Blocking: | Blocked by: |
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
Change History
comment:1 Changed 2 years ago by rwaldron
- Priority changed from undecided to high
- Component changed from unfiled to attributes
comment:2 Changed 2 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.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
