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

Optimize css() some #233

Merged
merged 4 commits into from
Apr 20, 2017
Merged

Optimize css() some #233

merged 4 commits into from
Apr 20, 2017

Conversation

lencioni
Copy link
Collaborator

I am pulling these commits out of #216 because I think they are pretty straightforward and should be easier to merge in this way.

After the 1.2.0 release, I noticed that most of my optimizations were
completely offset by the ordering bugfixes that were added. After some
profiling, I noticed that generateCSSRuleset was ripe for optimization.

My approach here is to reduce the amount of work that needs to be done
to a bare minimum. I accomplish this by being smarter about when to loop
and how many loops to run. In my benchmark, this PR reduces the runtime
of css() from 3200s to 2150 ms, which is 1.49x faster.
This is a micro-optimization. We can eek out a tiny bit more performance
by moving the function declaration up to the module level. I decided to
put it next to the related functions in the util module.
This is a tiny optimization that helps us avoid this check from
happening inside the loop.
I noticed that we loop over every declaration in this method, seeing if
there is a stringHandler available for it. However, it is more likely
that there will be fewer stringHandlers than declarations, so we can
speed this up by inverting the loop and check here.

While I was at it, I decided to prevent this method from creating a new
OrderedElements object every time and instead to just mutate it. I
believe this will be safe and should buy us more performance. This means
we no longer need the .map method on this class.

This change reduces the time spent in runStringHandlers from 8.6% of
css() runtime to 0.26% and brings the runtime of my benchmark down from
2150ms to 1950ms.
@lencioni lencioni requested a review from xymostech March 23, 2017 17:16
@lencioni lencioni mentioned this pull request Mar 23, 2017
@lencioni
Copy link
Collaborator Author

@xymostech this PR should be pretty straightforward and unblocks some of the improvements I wanted to do on #216. Any chance you are able to take a look soon?

Copy link
Contributor

@xymostech xymostech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Sorry this took so long to get to, work's been busy. Merge away, and I'll take a look at #216 again.

Just to make sure, this doesn't fix #231, correct? It's fixed in the extra commits of #216?

@lencioni
Copy link
Collaborator Author

lencioni commented Apr 15, 2017 via email

@lencioni lencioni merged commit 86d6189 into master Apr 20, 2017
@lencioni lencioni deleted the some-optimizations branch April 20, 2017 18:40
@lencioni
Copy link
Collaborator Author

To close the loop a bit, v1.2.1 just went to production for Airbnb, and it reduced our server rendering times by ~15% (v1.2.0: 285ms, v1.2.1: 245ms). Obviously, this will also help on the client side as well, but the numbers are a little more challenging to consistently measure there.

@xymostech
Copy link
Contributor

Thank you so much for pushing this forwards, @lencioni! Glad to hear that it improved performance! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants