Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check before setting style property #2551

Closed
wants to merge 2 commits into from
Closed

Check before setting style property #2551

wants to merge 2 commits into from

Conversation

morris
Copy link

@morris morris commented Aug 22, 2015

According to this jsperf, checking if a style property has changed before setting it gives a speedup of 40% (Chrome) to 80% (Firefox) if the value is the same. This check is also hard to to in userland because the user would have to replicate camel case, vendor prefixes, hooks etc. which are applied inside jQuery.style.

According to [this jsperf](http://jsperf.com/check-style-attributes-before-setting-or-just-constant-), checking if a style property has changed before setting it gives a speedup of 40% (Chrome) to 80% (Firefox) if the value is the same. This check is also hard to to in userland because the user would have to replicate camel case, vendor prefixes, hooks etc. which are applied inside `jQuery.style`.
@gibson042
Copy link
Member

This seems unobtrusive, and I have no objection in principle, but can you provide a real-world scenario where this actually affects broader application performance?

@dmethvin
Copy link
Member

Is the most common case that .css() is trying to set the same property value over and over again? It seems like you'd want to test and bias towards the case where the current value is not the same, because there the added if is performing extra unnecessary work.

The current code runs about 2 million operations per second or 0.5 microseconds per operation. When jsperf starts reporting numbers like that on microbenchmarks you really need to be careful about interpreting them, and wonder whether it matters at all.

The worst case scenario would seem to be animations, and for animating a property you'd call this at most 60 times a second for a total cost of 30 microseconds, or 0.2 percent of your 16 millisecond frame. The style and layout work provoked in the browser by most CSS changes will often be one or two orders of magnitude bigger. I wouldn't think it's common in animations to set the same property over and over, but when it does happen we're not gaining much from avoiding it and we don't yet know the cost of checking for it when it's not common.

@morris
Copy link
Author

morris commented Aug 23, 2015

Valid points, I really overinterpreted the benchmark I posted. I ran another benchmark which sometimes randomly sets a different value (something like Math.random() < 0.01 ? 'red' : 'blue') and for most properties the check I wanted to introduce only pays off if the value is unchanged 99.9% of the time which is very unlikely; otherwise the regular css() is faster. It also seems browsers handle the case of setting the same value again pretty well. Sorry for taking your time!

@morris morris closed this Aug 23, 2015
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants