| Summary: | Non-reproducible Speedometer 2.1 scores | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Vladimir Prelovac <vprelovac> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Mac (Intel) | ||
| OS: | macOS 13 | ||
|
Description
Vladimir Prelovac
2022-10-23 21:59:50 PDT
You can take a look at Production build configuration to see the differences. I would guess that it's mostly ThinLTO and PGO. Closing as INVALID, as this does not describe a bug that needs to be fixed in WebKit. Thanks @Alexey Proskuryakov for looking into this, I appreciate it.
> You can take a look at Production build configuration to see the differences.
I looked into the avaialble WebKit documentation and I could not find a reference to the Production build.
I wonder if you could point me in the right direction how to run a Production build?
The differences are in DebugRelease.xcconfig files in source code. @Alexey Proskuryakov After a lot of looking around I was able to find Tools/Scripts/build-and-collect-pgo-profiles which referneces two techniques you describe and uses: make release WK_LTO_MODE=thin ENABLE_LLVM_PROFILE_GENERATION=ON It also then proceeds to run various benchamrks and collect PGO data. Looking good! Question: How do I run the rebuild process to include the PGO data folder? Thanks Alexey I was able to figure it out eventually. I wonder if the Production build should be better documented to benefit the wider community? Such documentation would be welcome indeed. It is not straightforward for us to do because most differences are related to how Apple internal build system works, and are thus irrelevant to everyone else. Distilling steps necessary to apply performance optimizations is valuable. Great to know that you were able to achieve parity! A "Production" build produces 20% performance improvement over Release WebKit. So anyone working With WebKit would benefit, especially as the gain is 'free' (just build process optimization). What is the best way to structure this documentation contribution? (as in where in repo) In the past, I'd say trac.webkit.org, but looks like people are de facto using GitHub wiki these days. |