3 ms·

Constellation’s PRs are incredible. Some of my favorites - 9x faster Array.from({length: N}, map) https://github.com/WebKit/WebKit/pull/2876 https://github.com

• capableweb 4y ago
  Some interesting writings by same person here: http://constellation.slowstart.org/blog/ 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.
  • colordrops 4y ago
    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.
  • eyelidlessness 4y ago
    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-reviewers https://webkit.org/commit-and-review-policy/#criteria-for-re... 2: https://webkit.org/blog/tag/reviewers/ https://webkit.org/blog/tag/reviewers/
    • capableweb 4y ago
      That probably explains it! Thank you for explaining it.
    • olliej 4y ago
      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.
      • eyelidlessness 4y ago
        Excellent clarification thank you.
  • olliej 4y ago
    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?
  • Lwrless 4y ago
    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.
• deleted 4y ago
  [deleted]
• hahnchen 4y ago
  These are definitely incredible. Wonder how one can know to find and make these optimizations
  • olliej 4y ago
    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
    • saagarjha 4y ago
      Most of these tests are attached to the pull requests with metrics on how the microbenchmarks improved :)
  • saagarjha 4y ago
    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.