Runtime performance improvements

[elsassph]

Issue #28 suggests to use the "inline react elements" optimization for production code.
cf. facebook/react#3228

This PR enables the literal objects optimization when building in release mode.
It can be disabled by setting -D react_no_inline.

This optimization affects both JSX code AND direct uses of React.createElement.

Note:

• there is an automatic de-optimization when using ref with a String value (in practice we're deoptimizing unless we are sure the ref is a function); it requires the full createElement context,
• you can force de-optimization for components which require the React context by adding @:reactContext meta to the component class,
• possible breaking change: now using Object.assign instead of React.__spread as deprecated by React v15.

Additional changes:

• React Hot Reload 3 tagging option (-D react_hot): in debug mode, adds a __source property to ReactComponent classes,
• displayName is now only generated in release mode.

[elsassph]

@francescoagati @zabojad @kevinresol feedback welcome

[francescoagati]

for me is good. Tomorrow i try to test in a project.

[elsassph]

I'll probably revert the Object.assign change, __spread still works in React v15 and it would require a polyfill.

[elsassph]

Nevermind, Object.assign is staying: React v15 just maps __spread to Object.assign so the polyfil will be needed anyway for IE and mobile...

[francescoagati]

yes object.assign isn't supported from many browsers

[francescoagati]

i get two errors. One is this with props and dangerouslySetInnerHTML

the seconds is with dce full i get Uncaught ReferenceError: $$tre is not defined.
$$tre is eliminated from dce

[elsassph]

@francescoagati I pushed a fix for dce; can you give me a minimal example for the other problem?
I could use dangerouslySetInnerHTML without problem.

[francescoagati]

for the sample tomorrow i try to create an example for the first error.

[francescoagati]

i think the problem is when props are empty for example in

---

{ '$$typeof' : $$tre, type : "hr", props : null, key : null, ref : null},blocks]}, key : null, ref : null};

i have see that with createElement active the property props isn't null

[francescoagati]

see this https://github.com/babel/babel/blob/master/packages/babel-plugin-transform-react-inline-elements/src/index.js#L32

[elsassph]

Good catch, it's fixed now.

[francescoagati]

yeah now work all! and is really fast. Thanks really good work. now with inline of react elements and inline of haxe functions the rendering is really fast

[francescoagati]

is really fast the initial rendering and also the updates

[elsassph]

Cool, is that really measurably faster for you? Did you profile it?

[francescoagati]

not profiled but seeing the rendering startup the difference is visible

[francescoagati]

founded some benchmarks for inlining. https://medium.com/doctolib-engineering/improve-react-performance-with-babel-16f1becfaa25#.4lzfezjm3

[elsassph]

@francescoagati @zabojad @kevinresol added another optimization to generate more compact inline elements. There's an option to have the less compact but monomorphic variant using -D react_monomorphic.
Can someone do some actual profiling to see if there is a difference when using compact VS monomorphic? Plus some numbers about the literal syntax improvements would be nice to have.

[elsassph]

About monomorphic option, we've got this note from Facebook: "On the React team we've been operating under the assumption that it's better to include the nulls."

[francescoagati]

i think that monomorphic are good for performance
http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.html

[elsassph]

Yes it is "in theory" better, but nobody seems sure if for the particular case of inline react elements it will help a lot considering we are generating more code and creating more complex objects.

[francescoagati]

read this comment on inferno infernojs/inferno#8 (comment)
inferno is similar to react and use monomorphic objects in template

[elsassph]

Anyway I also think it's good but we need numbers ;)

[kevinresol]

@elsassph I tried the literal branch and it compiles fine with my codebase. And I didn't notice any runtime bug yet. I think the performance has been slightly improved on my side (because my rendering is not very heavy anyway), but yeah, just eyeballing, no numbers. I am not very sure how to profile react apps, any quick guides for that?

[elsassph]

For profiling you can typically use Chrome's Timeline in the debugging tool.

[elsassph]

ping @jeremyfa

[elsassph]

@francescoagati @zabojad @kevinresol added a last safety (inlining breaks components which need accessing the context): inlining should not happen for extern React component (should resolve problems with react-router) and you can prevent it manually by adding @:reactContext. I didn't try with redux; maybe you'd have a better suggestion for heuristics here.

[zabojad]

First tests on a little Apache Cordova project with this branch + react 15 and everything seems to work just fine in both dev and prod modes... It's a little project involving react-router and react-redux... I'm gonna try on a much larger project within the next 7 days...

[elsassph]

Ok I'll merge then - I'm tagging current master as 0.4.0 so you can keep pointing on it if needed.