Latest Results
Parallelize runs of in-lang tests and shorten storage tests compilation (#7661)
## Description
This PR:
- shortens the compilation time of storage in-language tests by marking
the generic `<...>_impl` functions as `#[inline(never)]`,
- parallelizes execution of in-language tests.
Combined, this reduces the execution time of the whole in-language test
suite from ~6 minutes to ~1 minute.
All storage tests have the same structure, testing a particular storage
type for different stored types by calling a generic, usually large,
`<...>_impl` function for each stored type. Since every monomorphized
`<...>_impl` call happens only once, inlining pass will inline them all
in a single large function. This creates a lot of preassure on our
current inlining algorithm.
We will improve the inlining in dedicated optimization PRs. Until then,
this PR gives us better test compilation times for storage tests.
Compiling all storage tests sequentially before took ~4 minutes and
after forbidding inlining takes ~3 minutes.
Running tests sequentially is still kept as default, to make sure the
current performance script that extracts gas works as-is. Eventually
adapting that script and having only the parallel running will be done
in a follow up PR.
## Checklist
- [ ] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Optimize compilation speed and memory consumption (`DeclEngine`) (#7659)
## Description
This PR improves compiler's memory consumption and compilation speed by
removing duplicated entries from the `DeclEngine`. The PR also removes
many of the unnecessary cloning of various type declarations.
When compiling o2 `order-book` contract:
- the memory consumption **reduces from 3.85 GB to 1.06 GB**,
- the compilation time **reduces from ~6.1 to ~4.1 seconds**.
Compilation time improvements are also reported by CodeSpeed:
| | Benchmark | `BASE` | `HEAD` | Efficiency |
| --- | --------- | ------ | ------ | ---------- |
| ⚡ | `` compile `` | 5.4 s | 4.6 s | +18.74% |
| ⚡ | `` open_all_example_workspace_members `` | 8.6 s | 7.4 s | +16.8%
|
When compiling the o2 `order-book` contract, the number of declarations
on the `DeclEngine` reduced as following (only biggest three slabs
shown):
| Slab | Length/Capacity Before | Length/Capacity After |
| ---- | ---------------------- | --------------------- |
| function_slab | 464_769 / 524_288 | 110_517 / 131_072 |
| struct_slab | 87_852 / 131_072 | 84_530 / 131_072 |
| enum_slab | 25_892 / 32_768 | 23_125 / 32_768 |
## Approach
To efficiently develop large Sway applications like o2 we need to reduce
compiler memory consumption and compilation time. `DeclEngine` was
holding large number of duplicated declarations, redundantly inserted
during different compiler phases, e.g., monomorphization. Implementing
[SemanticDefinitions RFC](https://github.com/FuelLabs/sway-rfcs/pull/51)
will remove all of those duplicates by changing how monomorphization
work.
Implementing `SemanticDefinitions` will require a long(er) roadmap. To
get more performant compiler immediately this PR checks if declarations
to be inserted are actually changed compared to originals that are
already in the `DeclEngine`.
Note that this practice was already used in some cases, where
`HasChanges` was checked after calling `subst`, but these cases were
very rare.
## Side-effects
Assuming how intertwined type checking, type unification, type
inference, and monomorphization is, I've expected more side-effect of
removing the duplicates, but it turned out there were only two:
- DCA got improved and in two cases (order-bool contract and
`unused_return_value` test) reported two additional warnings that are
valid warnings and were not reported before.
- recursion detection got broken. An attempt to analyze the issue and
maybe fix it is described in #7658. As described in that issue,
recursion detection must not depend on duplicates being inserted.
Essentially, the current implementation relies on an unwanted behavior.
Because the probability of having recursive methods is rare, and there
is no miscompilation (compiler overflows), this issue can be analyzed
and fixed in a separate PR so that we can immediately have the benefits
of not-inserting duplicates in the `method_application`.
Aside from these two changes in the compilation process, the compilation
output (bytecode) remained the same.
## Next Steps
Additional improvements can be done in subsequent PRs.
- `HasChanges` enum is still defined in `subst_types`. It should be
moved to some common place. [Code quality]
- Notifying changes to caller is done in three different ways: returning
`HasChanges`, returning `bool`, or not returning information at all. We
want to have `HasChanges` everywhere as an established pattern. [Code
quality]
- `HasChanges` should be marked as `#[must_use]` with appropriate hint
message. This will help to not forget to check the change and also to
easy discover additional places where we, e.g., insert into `DeclEngine`
although there are no changes. [Code quality, Performance]
- As the above table shows, we still have a large number of duplicates
in the `DeclEngine`. A part of the reason is that we still insert same
monomorphized types if they are created by monomorphizing the same
parent with the same generic arguments but in different places in code.
We can explore approaches to remove these duplicates as well. E.g, have
hashing/cashing inside of the `DeclEngine` to avoid duplicates, while
avoiding at the same time hashing cost of large decls like
`TyFunctionDecl`? Isn't that what `TyFunctionSignature` is doing?
[Performance]
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Refactor `InstOp::GetConfig` for consistency (#7656)
## Description
This PR refactors the implementation of the `InstOp::GetConfig`
instruction to make it consistent with the implementations of
`GetLocal`, `GetGlobal`, and `GetStorageKey` instructions. Having
implementations consistent reduces unnecessary effort in understanding
why `GetConfig` is different and how it works, especially when reading
the code for the first time.
The `InstOp::GetConfig` instruction was the only instruction that kept a
reference to the compiled programs `Module` as well as a parameter of
type `String`. The `Module` parameter is used in only one place to
retreive the type of the configurable and is otherwise ignored (`_`).
All other instructions exclusively keep their arena values. This
inconsistency required additional effort when reading and understanding
code. Moreover, what the instruction conceptually does, is the same as
the `GetLocal`, `GetGlobal`, and `GetStorageKey` instructions.
## Checklist
- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers. Latest Branches
0%
ironcev/rollout-has-changes +20%
ironcev/optimize-decl-engine-interactions -19%
ironcev/refactor-get-config © 2026 CodSpeed Technology