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.
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.
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.
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 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.
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.
- 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