react-juce icon indicating copy to clipboard operation
react-juce copied to clipboard

Measure cost of native function invocations from js

Open nick-thompson opened this issue 6 years ago • 4 comments

This comes from the longer term goal of implementing the 2d Canvas API via native calls to a juce::Graphics& instance; I want to understand the difference in executing a call to the graphics instance from native vs from the javascript environment to get a sense of how practical this would be from a performance standpoint. I think even a simple benchmark would do:

for (int i = 0; i < 100000; ++i) {
  g.drawRect(0, 0, i, i);
}

vs binding a call to g.drawRect into the js interpreter, and running

js.evaluate(R"
  function test() {
    for (let i = 0; i < 10000; ++i) {
      ctx.drawRect(0, 0, i, i);
    }
  }
");
// Measure this:
js.invoke("test");

nick-thompson avatar Dec 07 '19 17:12 nick-thompson

I'd be super interested in this also @nick-thompson. I intend to do a hefty amount of profiling once the canvas pr is merged.

Incidentally, I understand blueprint is currently using the standard duktape header and CPP files but duktape offers many build customisation options which generate a new duktape.h etc. Might be useful to document/facilitate this in Blueprint. My main concerns are going to be around memory usage and I suspect I might end up applying some tweaks.

JoshMarler avatar May 25 '20 21:05 JoshMarler

Fantastic, I'd be thrilled if you want to do some profiling! Very curious to see the results.

Yea, you're totally right that there might be better ways to optimize the included duktape installation. I'm not totally convinced that shipping duktape within blueprint is the right thing to do, but I originally made the decision because I wanted to heavily prioritize making it super easy to get up and running. I'd be very interested in your thoughts here as you're doing this study

nick-thompson avatar May 25 '20 21:05 nick-thompson

Yeah interesting question, particularly if you adopt the pimpl idiom in EcmaScriptEngine to facilitate other interpreters. Maybe then it's down to the user to fetch the source for whichever interpreter implementation they desire and just set include paths etc.

JoshMarler avatar May 25 '20 22:05 JoshMarler

Definitely. Maybe we can include a "default" duktape in there that facilitates people getting up and running super easily, but provide an easy "opt out" flag that lets you swap in a different backend (V8, JavaScriptCore, or even just a differently-compiled duktape) that fits your needs

nick-thompson avatar May 25 '20 22:05 nick-thompson