[JS] Reduce WASM call overhead about yoga HOT 6 OPEN

Here's some more info about my benchmark. I updated my original post as well. Environment: Windows 10, Chrome 120.0.6099.200, Yoga 2.0.1. The benchmarks in Firefox have lower times, but the ratio between Yoga execution and getting the computed results is the same, if not worse.

If you guys can double check the results, that would be great. Hopefully there is not something with my environment or configuration that is causing these results.

Benchmark source code:

async function main() {
  const yoga = await loadYoga();
  postProcessingBenchmark(yoga, 2500);
}

function postProcessingBenchmark(yoga, numChildren) {
  const root = createRoot(yoga, numChildren);
  let start;

  start = performance.now();
  root.calculateLayout(10, 10);
  console.log("Yoga computation: ", performance.now() - start);
  start = performance.now();
  postProcessingLoop(root);
  console.log("Getting computed values: ", performance.now() - start);
}

function createRoot(yoga, numChildren) {
  const root = yoga.Node.create();
  root.setWidth(10);
  root.setHeight(10);

  for (let i = 0; i < numChildren; i += 1) {
    const node = yoga.Node.create();
    root.insertChild(node, i);
  }

  return root;
}

function postProcessingLoop(node) {
  const result = {
    paddingLeft: null, paddingRight: null, paddingTop: null, paddingBottom: null,
    marginLeft: null, marginRight: null, marginTop: null, marginBottom: null,
    borderLeft: null, borderRight: null, borderTop: null, borderBottom: null,
    computedLayout: null
  };

  result.paddingLeft = node.getComputedPadding(Edge.Left);
  result.paddingRight = node.getComputedPadding(Edge.Right);
  result.paddingTop = node.getComputedPadding(Edge.Top);
  result.paddingBottom = node.getComputedPadding(Edge.Bottom);

  result.marginLeft = node.getComputedMargin(Edge.Left);
  result.marginRight = node.getComputedMargin(Edge.Right);
  result.marginTop = node.getComputedMargin(Edge.Top);
  result.marginBottom = node.getComputedMargin(Edge.Bottom);

  result.borderLeft = node.getComputedBorder(Edge.Left);
  result.borderRight = node.getComputedBorder(Edge.Right);
  result.borderTop = node.getComputedBorder(Edge.Top);
  result.borderBottom = node.getComputedBorder(Edge.Bottom);

  result.computedLayout = node.getComputedLayout();

  for (let i = 0; i < node.getChildCount(); i += 1)
    postProcessingLoop(node.getChild(i));
}

from yoga.

I read the 'embind' documentation you posted Nick.

From the performance section at the bottom of the page:

The call overhead for simple functions has been measured at about 200 ns. While there is room for further optimisation, so far its performance in real-world applications has proved to be more than acceptable.

This makes perfect sense with what we're seeing. 200ns * 2500 nodes * 13 API calls = 6.5ms. I didn't account for the calls to getChildCount() and getChild() as well while iterating through nodes, so that adds even more time. This doesn't account for all of the time, but it's certainly a ton of overhead.

from yoga.

This seems like a sensible proposal to me. Crossing the WASM boundary is indeed expensive. And in my testing, batching calls helps significantly (esp. in Firefox, which was already faster than Chrome). I have some performance experiments with WASM builds of Taffy and Yoga on this branch DioxusLabs/taffy#394

It's also the case that Chrome's WASM implementation is just generally not very optimised compared to the one in Firefox. So if you're testing in Chrome then there is probably room for optimisation in the WASM-implementation itself.

from yoga.

Wow, that’s a lot of overhead.

One more layer we have in here is “embind”. https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html

I’ve been keen on removing it for some unrelated reasons (#1507), but a solution for both of these might be to move the bindings to Emscripten direct function calls. https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#interacting-with-code-direct-function-calls

I think this might lower call/bridging overhead, and the Yoga public API being C should have nice mappings for this most of the time. But I haven’t measured if this has a real impact.

from yoga.

Would you be able to share the code used for the example, where chunkier accessor improved performance?

from yoga.

If you are using Yoga in a case where your source may mutate over time, incremental Yoga layout can avoid the majority of the traversal, both for calculating, and later reading layout results.

But we are missing a trivial binding for the api for this #681

from yoga.