Performance Tuning

[sebas5384]

Considering we are using webpack, maybe we should use it in order to remove this:

require("node-jsx").install(
  {
    "extension":  ".js",
    "harmony":    true
  }
);

at every init.js of projects that use ambidex.

Any thoughts?

[appsforartists]

iojs doesn't yet support the full suite of JS Harmony transforms that node-jsx does.

Even if it did, there's a comfort in knowing the same transformation (jstransform) is being applied to both client and server code. That prevents tiny inconsistencies between the runtimes from causing hard-to-trace bugs.

[sebas5384]

That comfort we can get it with a server bundle being generated by webpack too, theres an example here: https://github.com/webpack/react-starter/blob/master/make-webpack-config.js#L130

[off-topic] Why did you close the issue?, you even let me continue, please be more patience if this project is aiming to get a community around, its healthy. Just trying to be friendly :+1:

[appsforartists]

No disrespect intended. I try to keep the open issues list clean (e.g. only inclusive of things that need active work). I'm not yet convinced that node-jsx needs to be replaced, but I'm happy to reopen this if you can convince me. Closing doesn't mean "I don't want to talk about this", just that "I don't yet see a reason to make a change." We can keep talking as long as you like.

I didn't realize that Webpack had a Node target; that's good to know. Still, is it actually faster? node-jsx should only run when a module is first require()ed, which means the surface area for slowness is pretty small - it shouldn't have any affect on the speed of your app after startup. I'd be really surprised if Webpack is faster, since both node-jsx and Webpack's jsx-loader are running jstransform, but Webpack has other nontrivial pieces too. That means it's going to use both more CPU and more RAM to do the same task.

What parts are slow for you? Does Webpack do them faster?

One thing I know I'm going to need to eventually change is to make each instance of Ambidex run in its own thread, so we don't hit Node's <2GB memory ceiling. Until that happens, starting the TardisGallery is slower than it should be.

There's room for performance testing in all sorts of places, so if you find a specific area that is slow and have a proposal to improve it, please let me know.

[sebas5384]

Thanks for the reply. Developing an app with the react-starter, was taking less than 15s to boot, but with Ambidex is taking almost 21s. And every time I add node-jsx to a project it gets a lot slower to boot, so I thought, maybe is that.

I'm gonna study more about this to see if I can reduce that boot time.

[appsforartists]

Please let me know what you find.

FWIW, I just started our non-trivial demo on my 2.6Ghz Core i7 MBP. This demo has 9 instances of Ambidex running in parallel, so it definitely hits the Node memory limit. The node-jsx portion of the app was ready-to-serve in under 5 seconds, though the Webpack Dev Server didn't start for another 26 seconds after that.

[sebas5384]

One thing I know I'm going to need to eventually change is to make each instance of Ambidex run in its own thread, so we don't hit Node's <2GB memory ceiling.

@appsforartists what information you have about this? I'm gonna need to help you in that. Why do you think is needing so much memory?

Take a look at this, the "ambidex-d8" is our app:

[appsforartists]

Honestly, performance tuning is not my forté. I'm very amenable to help in this area.

I see you have many d8-ambidex processes running. Are those all apps that you've npm started separately (presumably running on different ports)?

The projects I've used Ambidex on use TardisGallery to serve many Ambidex instances from the same process. If I were to take a stab at performance tuning, the first thing I'd do is research how to get each of those to live in its own process, so it could have its own separate memory allocation. I'd also see if there are any perf benefits to running each instance of Webpack in its own process.

[orourkedd]

I think its leaving out the extension that slows it down. It must have to analyze too many files unless the extension is specified. When I specify an extension (below) it fixes the slow boot issue.

require('node-jsx').install({
  extension: '.jsx'
});