Live data from Hacker News

Interview with the author of React-like Inferno about JavaScript optimisations

survivejs.com

41–50 of 51 posts

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#41

Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this: http://youtu.be/BEqH-oZ4UXI .

So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage?

"Anonymous" function calls (function expressions, either immediate or not) are generally only more expensive because they're re-created all the time. Sometimes this is necessary to create a closure, often it's not. If you were to profile `var foo = function() {}`, performance should match the function declaration variant identically, so it's not the method of declaration that affects performance.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#42
post #4
post #2

Sadly, this article has nothing to do with an inferno OS port to js. http://www.vitanuova.com/inferno/

Agreed and similarly disappointed. Can we please change the title to point out that this is specific to ReactJS?

OK, we've attempted to do that and still be accurate.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#43
post #20

I've spent a lot of time optimizing the startup time of large React codebases. In my experience the size of the React bundle is irrelevant; it will be quickly dwarfed by the product code for any meaningful application. The real problems in startup speed are twofold: Browsers are stuck optimizing an outdated model - parsing and compiling JavaScript on the critical path is madness. The only benefit of that model is tha…

Note: I'm the author of Inferno I commonly hear the same thing – you've benchmarked React and it performs fine. Did you benchmark this on a modern MacBook/laptop by any chance? The realism is that the desktop market is only 15% of the entire global online market. In developing nations, Android mobile performance is essential. React, Angular, Ember and other libraries have never performed well in this space. If you're…

What are example real world websites using Inferno?

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#44

Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this: http://youtu.be/BEqH-oZ4UXI .

So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage? "Anonymous" function calls (function expressions, either immediate o…

That is something I have been suspecting of BenchmarkJS, which is unfortunate because I am/wasn't expecting to be responsible for building a better benchmarking tool (we are already building a database and a distributed testing framework).

FireFox does inline, and we can tell even with BenchmarkJS, which is why I think V8 wasn't (although it has improved significantly recently).

We ran an "actual use" test that saved 100M+ records a day for $10 total (on about 100GB+, processing, storage, backup). However since it is an "actual use" we don't know if inlining happened or not (I still suspect not, since I haven't seen that in V8 - but again, maybe that is BenchmarkJS killing it, despite seeing it in FF).

Correct correct. The function call is still expensive (anonymous or not), and managing scope is extremely expensive. You are on top of this stuff! Sounds like you do performance testing regularly?

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#45

Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this: http://youtu.be/BEqH-oZ4UXI .

Is there a written summary of this anywhere?

I tried to give a summary in the video description (click the view more). I hope that helps.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#46

Earlier quoted context omitted.

Is there a written summary of this anywhere?

I tried to give a summary in the video description (click the view more). I hope that helps.

Thank you, missed that

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#47
post #17
post #9

Earlier quoted context omitted.

Note: I'm the author of Inferno and know the authors of Preact and Ivi well. That's a great question and one I frequently get asked. The "current" React codebase is legacy in many ways, the React team are hard at work on React Fiber which is complete re-write of the entire codebase. The legacy codebase isn't something we can actively make better (I've had my PRs merged though) without a huge rewrite. If we tried to m…

I haven't kept up with React like I should. When you say they're undergoing a re-write, is this going to be like Angular 1 vs Angular 2? I just took a quick look at their react fiber demo page [0], is it going to be opinionated react as redux based? That's the vibe I'm getting from this. [0] http://reactbits.github.io/fiber/

You can think of it much more like putting a more advanced engine & drivetrain in a classic race car.

Practically speaking for an end user not a lot will change, but React will be faster, non-blocking, and have a whole new set of applications.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#48

Earlier quoted context omitted.

So I watched that and heard that you used BenchmarkJS which I believe intentionally prevents optimization from occurring, otherwise many tests would just end up being optimized away. Have you considered how function inlining might affect your results versus benchmarks like you ran in the video? Have you profiled them side by side under actual usage? "Anonymous" function calls (function expressions, either immediate o…

That is something I have been suspecting of BenchmarkJS, which is unfortunate because I am/wasn't expecting to be responsible for building a better benchmarking tool (we are already building a database and a distributed testing framework). FireFox does inline, and we can tell even with BenchmarkJS, which is why I think V8 wasn't (although it has improved significantly recently). We ran an "actual use" test that saved…

I do, but it's also easy to sound smart when you're standing on the shoulders of very smart people. @jdalton and @petkaantonov are two that I've regularly followed and read their code for learning purposes. IRHydra by @mraleph is a great tool for learning about V8 internals and examining what's going on under the hood. Bluebird is an amazing example to follow if you really want to optimize, however the vast majority of libraries and apps don't need to concern themselves with some of the crazier optimizations that are performed there.

The biggest takeaways that I've had are mainly that if you really want to optimize, then write the kind of code that the various engines can optimize best. With that in mind, TypeScript is not only a great language, it's actually a great performance tool since it can help you to identify polymorphic functions that maybe could be changed to monomorphic ones if they're in the hot path.

I've got another fun hacky kind of optimization for you though that I've mainly used for benefit in some angular code/expressions that are executed potentially millions of times. If you can make some assumptions about the name of the property being accessed for security reasons and it's going to be repeatedly used, compare the following:

// Setup

const makeGetter = (prop) => new Function("obj", "return obj." + prop");

const slowGetter = (obj, prop) => obj[prop];

const fastGetter = makeGetter("foo");

const obj = { foo: "bar" };

// Test

slowGetter(obj, 'foo');

fastGetter(obj);

This is primarily an optimization for Internet Explorer, but if I recall it was somewhat positive in other browsers at the time as well. It makes more sense if you consider it in the context of executing a simple angular expression repeatedly, though 1.6.0 might narrow that gap significantly now that the expressions sandbox was removed as I think they generate code similar to my "makeGetter" factory. Haven't re-tested yet.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#49
post #29

Earlier quoted context omitted.

>Browsers are stuck optimizing an outdated model Well, you can always switch to Java applets, Flash or Silverlight. Oh, wait... >parsing and compiling JavaScript on the critical path is madness. You know what's madness? Pushing so much client-side code that it destroys your website's performance - despite giant leaps in capabilities of CSS, expressiveness of the language itself, faster CPUs, and tons of engine optimi…

> You know what's madness? Pushing so much client-side code that it destroys your website's performance - despite giant leaps in capabilities of CSS, expressiveness of the language itself, faster CPUs, and tons of engine optimizations. And if I can't create something that fits well into that model then what should I do? Create a native app on a proprietary system instead? Change my product to fit the stunted capabili…

>And if I can't create something that fits well into that model then what should I do? Create a native app on a proprietary system instead?

Use Java, of course! I heard you write it once and it runs everywhere. And it doesn't rely on that horrible, outdated Web model. Compiles to binary blobs, just the way you like it.

Re: Interview with the author of React-like Inferno about JavaScript optimisations

#50
post #11
post #8

Earlier quoted context omitted.

React as an API is brilliant. A Couple of methods only. The libraries conform to the API and achieve different things. Preact is react but simple. It's very lightweight, readable and gets the job done. Inferno is heavily optimized at the cost of readability. React is the original project which is now a monolith. Smaller than angular but still big. Remember on average every 1Mb of JS Will take about a second to parse…

Size isn't everything ;-) A smaller footprint _does_ usually signify a faster load time, but that can easily be overruled by how its internals are parsed (aka, interpreted by the browser). For example, 1kb script can intentionally block the mainframe for 10seconds, thus making it slower than a 40kb moderate-performing competitor. Inferno is optimized for the entire performance profile. Preact may load & parse faster…

Inferno only works super fast if you use the babel transpiler that creates the blueprint calls. While this is a great idea, debugging it is a nightmare at times.

I'd rather have simple h or createElement calls. I personally prefer Typescript jsx as all my Components are type validate and refactoring is a breeze.

What I like about preact is its simplicity. I can debug preact and figure out what's going on. Inferno on the other hand seems a bit like assembly. Reusing property names across different contexts is a no-no in my book.

I once worked on a database with generic extra_1 extra_2,... fields. They were abused pretty bad and only one guy knew what they meant in what context.

While trueadm is a perf wizard I would definitely love to see some of the opts being done at the V8/chakra level rather than obfuscated js code.

Post reply on HN