Fast JavaScript-to-WASM Call from FTL | Hacker News Reader

Fast JavaScript-to-WASM Call from FTL

github.com

85 pointstosh15 comments

Open articleView on HN

Constellation’s PRs are incredible. Some of my favorites

- 9x faster Array.from({length: N}, map) https://github.com/WebKit/WebKit/pull/2876

- 35% faster Object.entries() https://github.com/WebKit/WebKit/pull/5281

- 4x - 6x faster new Proxy(obj).get https://github.com/WebKit/WebKit/pull/3674

- 1.5x faster “await” https://github.com/WebKit/WebKit/pull/4909

- for (let {destructured} of array) {} gets 2x faster https://github.com/WebKit/WebKit/pull/5477

- 15% faster JS -> WASM calls via better inlining caching https://github.com/WebKit/WebKit/pull/8077

- 2x faster typed array.slice https://github.com/WebKit/WebKit/pull/2694

Some interesting writings by same person here: http://constellation.slowstart.org/blog/

One thing I don't get, why they call themselves "WebKit reviewer", they've made tons of contributions (of high value) to WebKit, way beyond what I would think a "reviewer" would do.

Reviewer is a term of status for WebKit contributors[1].

> A potential Reviewer may be nominated once they have submitted a minimum of 80 good patches. […] A person who submits many patches but does not show good collaboration skills, code understanding or understanding of project policies may never be nominated.

And when someone becomes a WebKit Reviewer, their status is announced publicly under a special tag[2]. My interpretation (I’m happy to be corrected if mistaken) is that this status is essentially maintainer, but perhaps outside the team at Apple.

1: https://webkit.org/commit-and-review-policy/#criteria-for-re...

2: https://webkit.org/blog/tag/reviewers/

Webkit policy requires all reviewers be approved openly - it’s not possible for an Apple employee to land changes without a project approved reviewer. The reality is that the majority of webkit engineers and reviewers are employed by Apple, so an Apple engineer can always talk to a reviewer in person if they’re trying to get a faster turn around.

Similarly Apple employees have to go through the same nomination process to become reviewers, and are subject to the same requirements.

Excellent clarification thank you.

That probably explains it! Thank you for explaining it.

You can’t be a non-engineering contributor to webkit and a reviewer.

Basically: how can you be an effective reviewer if you aren’t able to write the code as well?

I’m unsure of any project that has otherwise uninvolved folk who are reviewers, and can’t imagine where that would make sense?

The blog is cool. I know a little Japanese. I really appreciate that all the technical terms are written in plain English instead of Japanese Katakana words.

Perhaps they are just being humble. For a system of this complexity it is hard to review without having the level of understanding that comes with contributing.

These are definitely incredible.

Wonder how one can know to find and make these optimizations

Profiling. So much profiling.

Of course for that to be relevant you need to have tests that can actually hit the relevant code paths.

The fastest(hah!) way to get performance of something fixed is to provide a easy to run deterministic and vaguely realistic example where performance is significantly worse in one case vs another. Now that could be one JS engine vs another, but it could also be a piece of JS calling two functions doing the same thing, only one in JS and one in wasm, or say a switch vs a series of if/else

Most of these tests are attached to the pull requests with metrics on how the microbenchmarks improved :)

Most of these provide specializations for specific operations that “should” get optimized but currently aren’t. They were probably pulled from some other code that was slower than it should be, isolated to the specific thing that wasn’t optimized, and then the heuristics were written to match it.

Will this work speed up WASM network and DOM interactions?

In theory, since those go through JavaScript they may see some wins. However this optimization only applies to the higher tiers of the JIT so your code may not be called enough or optimized to hit this path.

Reply on news.ycombinator.com