Stream: git-wasmtime

Topic: wasmtime / PR #14093 perf: cranelift-codegen-meta: reduce...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:33):

dishmaker opened PR #14093 from dishmaker:dishmaker/perf_isle_paths to bytecodealliance:main:

-0.1% less llvm lines

You can just close this PR if it's wasting your time :smile:

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:33):

dishmaker requested wasmtime-compiler-reviewers for a review on PR #14093.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:33):

dishmaker requested alexcrichton for a review on PR #14093.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:43):

cfallin commented on PR #14093:

@dishmaker can I ask what the overall goal with these PRs is? You're optimizing the size of build-time meta-code, and in tiny (trivial 0.1% shifts) ways and in some places in ways that makes the code less idiomatic or harder to trace through (e.g. prior vec-push vs. array-literal PR), which doesn't really affect Cranelift's critical path in any real way as far as I'm aware. Is there a broader goal of making binaries smaller or somesuch?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:52):

:cross_mark: dishmaker closed without merge PR #14093.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 15:52):

dishmaker commented on PR #14093:

I'm trying to reduce compile times in debug and binary size in release.

cranelift-codegen depends on:

<img width="544" height="687" alt="image" src="https://github.com/user-attachments/assets/8f637341-410d-4b08-9ba5-7eb6c0021a3a" />

view this post on Zulip Wasmtime GitHub notifications bot (Aug 08 2026 at 17:24):

cfallin commented on PR #14093:

Sure, faster builds of the build script itself are a priority; we've indeed been careful to keep deps minimal there.

That said I'm not sure "0.1% fewer LLVM IR lines" justifies a lot of PRs, review traffic, and sometimes nontrivial changes to control flow if the build-time effect is also in that neighborhood (and it could be less if trivial differences are optimized away early in the LLVM pipeline). Have you measured a speedup in build time? I'm happy to see these through if you've got that data. Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Aug 10 2026 at 14:22):

alexcrichton commented on PR #14093:

Personally I think PRs like this are ok so long as we're not completely inundated, which I don't think we are just yet. Historical profiling I've done shows a pretty strong correlation between "less IR is faster to compile" and while small percentage points probably won't move the needle massively they can accumulate over time to provide nice wins. So long as none of the code is massively changing and it's basically just minor refactors it seems ok to me to land PRs like this.

If you've got a lot of PRs @dishmaker though it's probably best to lump multiple changes into one PR, for example everything applicable to one file, with separate commits for ease-of-review.

Last updated: Aug 30 2026 at 09:07 UTC