Optimize _bindAutoBindMethods

[mridgway]

We are running into some performance issues using React on the server side. In large component trees, we are finding that render time increases linearly. In our case, we are seeing render times over 80ms for a relatively simple page (112 components). During profiling we have found that the _bindAutoBindMethods is showing up at the top of our trace:

   ticks  total  nonlib   name
    245    0.6%    0.6%  LazyCompile: ~L._bindAutoBindMethods /Volumes/Projects/app/node_modules/react/dist/react-with-addons.min.js:13
    146    0.4%    0.4%  LazyCompile: ~L.mountComponent /Volumes/Projects/app/node_modules/react/dist/react-with-addons.min.js:13
     75    0.2%    0.2%  LazyCompile: Join native array.js:119
     72    0.2%    0.2%  LazyCompile: bind native v8natives.js:1578
     64    0.2%    0.2%  LazyCompile: ~i.createElement /Volumes/Projects/app/node_modules/react/dist/react-with-addons.min.js:14
     45    0.1%    0.1%  Callback: execute
     38    0.1%    0.1%  LazyCompile: hasOwnProperty native v8natives.js:249
     37    0.1%    0.1%  LazyCompile: *parse native json.js:55
     31    0.1%    0.1%  LazyCompile: *n /Volumes/Projects/app/node_modules/react/dist/react-with-addons.min.js:16

I went in and added hrtime() calls inside _bindAutoBindMethods to see how much time was contributing to the rendering, and found that over 23ms was used just within this method. This may not seem like a lot, but this has pretty dramatic effect on throughput when the server is rendering synchronously.

Is there a way to optimize this so that binding happens lazily? On the server, many of the methods may not even be called (event handlers, lifecycle events, getDOMNode, etc.).

[zpao]

cc @sebmarkbage. We were talking about changing the autobinding recently. He might have some insight here (especially in context of ES6 classes)

[sebmarkbage]

The idea is to move to an explicit binding model using ES6 classes + maybe property initializers. This lets you choses whether to bind at construction time or as they're used in render according to your optimizations.

Maybe there is a way we could change the optimization for server side render but I doubt it since in theory you'd need to bind it at least once even on the server. It's possible to call a callback in componentWillMount.

I would also suggest that you try a different strategy for benchmarking. Profiling tools tend to exaggerate small methods that gets called a lot.

If you comment out the call to _bindAutoBindMethods in React, and then profile by manually timing the whole operation, without a profiler enabled... Do you see the same results?

[mridgway]

WRT to the profiling manually: that's what the hrtime test I mentioned above is doing. I removed the profiler and just used process.hrtime around the _bindAutoBindMethods calls and it added up to 23ms.

In ReactCompositeComponent#mountComponent:

        var startTime = process.hrtime();
        this._bindAutoBindMethods();
        var diff = process.hrtime(startTime);
        bindTime += (diff[0] * 1e9 + diff[1]);

Printing out bindTime at the end of rendering gives me the total nanoseconds used in _bindAutoBindMethods.

I will try removing the method to see how it effects total rendering time. I was concerned before that the render would break if this was removed for instance with componentWillMount.

[mridgway]

Yeah, unfortunately this breaks some of our components when testing without calling _bindAutoBindMethods, so I can't test the difference.

[syranide]

@mridgway Just to be safe, have you considered the cost of calling hrtime? (i.e. move _bindAutoBindMethods outside of it and leave it empty and measure) I don't know what you're rendering, but hrtime might be an expensive external call that prevents optimizations and it could contribute significantly to the cost. Probably isn't, but you never know... 23ms just seems too high...

[sophiebits]

You could also maybe try calling _bindAutoBindMethods twice to see what that adds?

[mridgway]

You're right: hrtime was contributing quite significantly as well. I re-ran the tests by combining a few calls to the method. I was able to get the single _bindAutoBindMethods measurement down to around 6ms on average by removing some of my debugging. By adding more calls as @spicyj mentioned I was able to get the difference between calling it twice and thrice:

• 1x: ~6.0ms
• 2x: ~8.1ms
• 3x: ~10.2ms

So altogether it looks like the _bindAutoBindMethods is only taking up about 2-3ms per render. This isn't nearly as bad as I initially thought. It is still surprising how long it takes, but with this number it's probably not worth any extra effort to minimize this impact before @sebmarkbage's changes are in.

We're still trying to figure out why our render times are so high though.

[mridgway]

No matter how I measure it, _bindAutoBindMethods is always the largest contributor to our latency/performance issues. By running applications side-by-side with benchmark.js on node, with stock React vs React with _bindAutoBindMethods commented out, I see 15% performance gains (ops/sec rendering app) with it commented out.

Migrating to ES6 components helps for our custom components, but not for the built-in components which use React.createClass.

It seems like there are two ways to mitigate this issue:

1. Migrate internal components to not use React.createClass or
2. Remove _bindAutoBindMethods so that classes created with React.createClass behave similarly to ES6 classes as far as binding

[jimfb]

Migrating to ES6, where possible, seems better. It's hard to justify optimizing a feature that is "not the future". We should increase the priority of migrating the built-in components to ES6 if we're really going to get a 15% perf boost on SSR.

[sophiebits]

@JSFB Not too hard to justify it when everyone uses it… but I don't know how to make autobinding faster.

[mridgway]

With NODE_ENV=production I'm seeing 20-25% improvement. This is in node.js using renderToStaticMarkup. This is the script I'm running to test: https://github.com/mridgway/flux-example/blob/bench/bench-chat.js. I am using React 0.13.1 from NPM and applied the patch from #3615 to make contexts work with multiple React's in same process.

[zpao]

Yea, not really hard to justify at all.

We're still talking about server-side here right? Perhaps there's something we can do so we don't actually create all the bound functions upfront? Maybe have placeholder functions which lookup the real function and use call?

[sophiebits]

@mridgway Can you try requiring 'react/dist/react.min.js' instead of the main React module as you're currently doing and compare?