Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support custom profiles instead of the predefines #1111

Closed
liuhongxuan23 opened this issue Feb 12, 2022 · 6 comments
Closed

support custom profiles instead of the predefines #1111

liuhongxuan23 opened this issue Feb 12, 2022 · 6 comments

Comments

@liuhongxuan23
Copy link

$ wasm-pack build --profile release-wasm
[INFO]: Checking for the Wasm target...
[INFO]: Compiling to Wasm...
error: conflicting usage of --profile=release-wasm and --release
The `--release` flag is the same as `--profile=release`.
Remove one flag or the other to continue.
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown" "--profile" "release-wasm"
@fbjork
Copy link

fbjork commented Mar 29, 2022

+1

mwu-tow pushed a commit to enso-org/enso that referenced this issue Jun 10, 2022
…file. (#3498)

### Pull Request Description

Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.  
(See key in first chart for the settings defining these profiles.)

We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.

Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.

### Performance details

![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)

As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.

<details>
  <summary>Methodology (click to show)</summary>

I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:

Build the application with profiling:
`./run.sh ide build --profiling-level=debug`

Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`

For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)

The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>

#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)

In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.

(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
@babymotte
Copy link

+1

ivan-aksamentov added a commit to nextstrain/nextclade that referenced this issue Oct 4, 2022
Here for wasm dev build I replace the `wasm-pack` which is nice, but behind its defaults it hides lots of useful stuff, and I call `cargo build`, `wasm-bindgen` and `wasm-opt` explicitly. Notably `wasm-pack` does not allow custom cargo profiles (rustwasm/wasm-pack#1111).

I also add the new "opt-dev" cargo profile, which is something in the middle between `release` and `dev` - a balance between rebuild speed and runtime performance. This should save lots of time during day-to-day work.

The production version still uses `wasm-pack` and a more tried solution.

The dev version now requires cargo wasm toolchain, `wasm-bindgen` and `wasm-opt` (from `binaryen` project) installed manually. Previously `wasm-pack` would handle that. The dev docker image was updated accordingly.
@mitiko
Copy link

mitiko commented Sep 21, 2023

This would be very useful for conditional compilation in staging environments, where binary size is still important but you need to do some extra logging for example.

@float3
Copy link

float3 commented Feb 18, 2024

Please implement this!

@float3
Copy link

float3 commented Feb 18, 2024

https://github.com/rustwasm/wasm-pack/blob/master/src/build/mod.rs#L103-L105 it looks like they don't specify a profile if you run wasm-pack with --dev

edit:

wasm-pack/src/build/mod.rs

Lines 103 to 105 in b9b3889

BuildProfile::Dev => {
// Plain cargo builds use the dev cargo profile, which includes
// debug info by default.

@net
Copy link
Contributor

net commented Mar 1, 2024

https://github.com/rustwasm/wasm-pack/blob/master/src/build/mod.rs#L103-L105 it looks like they don't specify a profile if you run wasm-pack with --dev

Unfortunately, that will also cause wasm-pack to use the debug target directory.

https://github.com/rustwasm/wasm-pack/blob/master/src/bindgen.rs#L26-L29

rafaelbeckel added a commit to rafaelbeckel/wasm-pack that referenced this issue Sep 3, 2024
@drager drager closed this as completed in 513feba Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants