Latest Results
chore(deps): lower opt-level for opendal-service-oss release builds (#7249)
## Problem Description
At `opt-level=3`, `opendal-service-oss` does not finish compiling after
**36 minutes of CPU**, spent single-threaded inside LLVM's SLP
vectorizer:
```
llvm::slpvectorizer::BoUpSLP::buildTreeRec
llvm::slpvectorizer::BoUpSLP::getScalarsVectorizationLegality
llvm::SmallPtrSetImplBase::insert_imp_big
```
This is the same pathology already documented in `Cargo.toml` for
`daft-parquet`, fixed the same way in #6690.
`src/daft-io/Cargo.toml` enables the `services-oss` feature, so the
crate is in the dependency graph of every release build.
`build-wheel.yml` carries no cargo cache, so `nightly-publish-s3.yml`
(cron `0 5 * * *`), `publish-dev-s3.yml`, and `publish-pypi.yml` each
recompile it from scratch. The pass is single-threaded within one
codegen unit, so it lands on the critical path.
## Changes Made
```toml
[profile.release.package.opendal-service-oss]
opt-level = 2
```
Six lines including the comment, mirroring the `daft-parquet` override
directly above it.
## Verification
The cause is the pass, not the optimization level. Holding `opt-level=3`
fixed and disabling only the SLP vectorizer:
| configuration | result |
|---|---|
| `opt-level=3` | 36 min 05 s CPU in a full build, 34 min 27 s CPU
isolated, neither finishing |
| `opt-level=3` with `-C llvm-args=-vectorize-slp=false` | 30.18 s wall
|
| `opt-level=2` (this PR) | **3.17 s wall** |
Scope is one crate. Of the service crates the opendal 0.57 split
introduced, at `opt-level=3`:
| crate | time |
|---|---|
| `opendal-service-oss` | exceeds 240 s, killed |
| `opendal-service-fs` | 28.4 s |
| `opendal-service-goosefs` | 18.1 s |
| `opendal-service-cos` | 3.3 s |
| `opendal-service-tos` | 3.1 s |
| `opendal-service-obs` | 3.0 s |
| `opendal-service-github` | 2.0 s |
- Full `make build-release` with this applied: **136 s** cold.
- The override is inherited by `release-lto`. Confirmed with `cargo
build --profile release-lto -p opendal-service-oss -Z unstable-options
--unit-graph`, which reports `opt_level=2, lto=fat`, so published wheels
benefit.
No test is included: this is a build-profile change, and its effect is
compile time rather than behaviour. `opendal-service-oss` performs
network IO against Alibaba Cloud OSS rather than compute, so
`opt-level=2` cannot affect Daft's numerical results and should not
measurably affect runtime.
## Related Issues
Fixes #7247
---
This PR was made with the assistance of Opus 4.8. Latest Branches
0%
DrishyaShah:feat/write-iceberg-upsert 0%
kyo-tom:support_iceberg_rest_catalog_on_gravitino 0%
AnayGarodia:fix/6991-unguarded-unwraps-progress-scan © 2026 CodSpeed Technology