perf(build): use line-tables-only debug info in the `dev` profile by Dandandan · Pull Request #24339 · apache/datafusion

Dandandan · 2026-08-13T17:19:27Z

Which issue does this PR close?

Adresses: #13814

Found while profiling compile times for #24325 / #24326 / #24329 / #24330,
which removed the trait-solving cost from the four crates on the critical path
and left LLVM as the dominant remaining cost.

Rationale for this change

dev is the profile behind every cargo build and cargo test, so its debug
info is generated over and over. debug = "line-tables-only" keeps file and line
numbers — panics and RUST_BACKTRACE output stay just as useful — and drops the
variable-level DWARF that only an interactive debugger consumes.

Measured per crate, interleaved with the baseline so machine drift cancels
out. The flag is passed to the crate under test only, so cached dependency
artifacts stay valid and nothing else moves between the two measurements:

crate	`debug = 2`	`line-tables-only`
`datafusion-physical-plan`	8.89s	7.43s	−16%
`datafusion-functions-aggregate`	5.86s	4.63s	−21%
`datafusion-physical-expr`	4.57s	3.59s	−21%
`datafusion-functions`	4.64s	4.04s	−13%
`datafusion-expr`	4.54s	3.57s	−21%
`datafusion-functions-nested`	4.37s	3.06s	−30%
`datafusion-optimizer`	3.91s	3.12s	−20%
`datafusion-common`	3.73s	3.10s	−17%
`datafusion-sql`	3.57s	2.43s	−32%
`datafusion-datasource-parquet`	3.27s	2.44s	−25%
`datafusion-datasource`	1.90s	1.42s	−25%
`datafusion-physical-optimizer`	1.22s	0.99s	−19%
sum	50.5s	39.8s	−21%

The saving is codegen-side, as you would expect: datafusion-catalog, which
spends its time in the trait solver rather than in LLVM, moves only 7.4s → 7.0s.

Artifacts shrink as well — libdatafusion_physical_plan.rlib goes from 141MB
to 100MB.

What changes are included in this PR?

One setting on [profile.dev], plus an update to the profile documentation block
above it, which currently advertises "full debug info" for dev.

Are these changes tested?

Are there any user-facing changes?

For anyone stepping through DataFusion in a debugger, local variable inspection
needs CARGO_PROFILE_DEV_DEBUG=2 cargo build (or a local override in
.cargo/config.toml); the comment in Cargo.toml says so. Everything else —
panic locations, backtraces, #[test] failures — is unchanged.

🤖 Generated with Claude Code

`dev` is the profile behind every `cargo build` and `cargo test`, so its debug info is generated over and over. `line-tables-only` keeps file and line numbers -- panics and `RUST_BACKTRACE` output stay just as useful -- and drops the variable-level DWARF that only an interactive debugger consumes. Measured per crate, interleaved with the baseline so machine drift cancels out. The flag is passed to the crate under test only, so cached dependency artifacts stay valid and nothing else moves: crate debug=2 line-tables-only datafusion-physical-plan 8.89s 7.43s datafusion-functions-aggregate 5.86s 4.63s datafusion-physical-expr 4.57s 3.59s datafusion-functions 4.64s 4.04s datafusion-expr 4.54s 3.57s datafusion-functions-nested 4.37s 3.06s datafusion-optimizer 3.91s 3.12s datafusion-common 3.73s 3.10s datafusion-sql 3.57s 2.43s datafusion-datasource-parquet 3.27s 2.44s datafusion-datasource 1.90s 1.42s datafusion-physical-optimizer 1.22s 0.99s ------------------------------------------------------- sum 50.5s 39.8s (-21%) The saving is codegen-side, as expected: `datafusion-catalog`, which spends its time in the trait solver rather than in LLVM, moves only 7.4s -> 7.0s. Artifacts shrink too -- `libdatafusion_physical_plan.rlib` goes from 141MB to 100MB. Verified that backtraces keep their file and line numbers under the new setting: thread 'main' panicked at datafusion/core/src/bin/print_functions_docs.rs:38:9 at ./datafusion/core/src/bin/print_functions_docs.rs:38:9 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

codecov-commenter · 2026-08-13T17:45:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.14%. Comparing base (ab12f5e) to head (50f75f1).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #24339   +/-   ##
=======================================
  Coverage   81.14%   81.14%           
=======================================
  Files        1112     1112           
  Lines      386933   386933           
  Branches   386933   386933           
=======================================
+ Hits       313967   313976    +9     
+ Misses      54476    54463   -13     
- Partials    18490    18494    +4

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

comphead

Thanks @Dandandan makes sense for local builds.

alamb · 2026-08-13T21:16:34Z

🚀

…ache#24339) ## Which issue does this PR close? Adresses: apache#13814 Found while profiling compile times for apache#24325 / apache#24326 / apache#24329 / apache#24330, which removed the trait-solving cost from the four crates on the critical path and left LLVM as the dominant remaining cost. ## Rationale for this change `dev` is the profile behind every `cargo build` and `cargo test`, so its debug info is generated over and over. `debug = "line-tables-only"` keeps file and line numbers — panics and `RUST_BACKTRACE` output stay just as useful — and drops the variable-level DWARF that only an interactive debugger consumes. Measured per crate, **interleaved** with the baseline so machine drift cancels out. The flag is passed to the crate under test only, so cached dependency artifacts stay valid and nothing else moves between the two measurements: | crate | `debug = 2` | `line-tables-only` | | |---|---|---|---| | `datafusion-physical-plan` | 8.89s | 7.43s | −16% | | `datafusion-functions-aggregate` | 5.86s | 4.63s | −21% | | `datafusion-physical-expr` | 4.57s | 3.59s | −21% | | `datafusion-functions` | 4.64s | 4.04s | −13% | | `datafusion-expr` | 4.54s | 3.57s | −21% | | `datafusion-functions-nested` | 4.37s | 3.06s | −30% | | `datafusion-optimizer` | 3.91s | 3.12s | −20% | | `datafusion-common` | 3.73s | 3.10s | −17% | | `datafusion-sql` | 3.57s | 2.43s | −32% | | `datafusion-datasource-parquet` | 3.27s | 2.44s | −25% | | `datafusion-datasource` | 1.90s | 1.42s | −25% | | `datafusion-physical-optimizer` | 1.22s | 0.99s | −19% | | **sum** | **50.5s** | **39.8s** | **−21%** | The saving is codegen-side, as you would expect: `datafusion-catalog`, which spends its time in the trait solver rather than in LLVM, moves only 7.4s → 7.0s. Artifacts shrink as well — `libdatafusion_physical_plan.rlib` goes from **141MB to 100MB**. ## What changes are included in this PR? One setting on `[profile.dev]`, plus an update to the profile documentation block above it, which currently advertises "full debug info" for `dev`. ## Are these changes tested? ## Are there any user-facing changes? For anyone stepping through DataFusion in a debugger, local variable inspection needs `CARGO_PROFILE_DEV_DEBUG=2 cargo build` (or a local override in `.cargo/config.toml`); the comment in `Cargo.toml` says so. Everything else — panic locations, backtraces, `#[test]` failures — is unchanged. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

…nto 9 (apache#24342) ## Which issue does this PR close? None. Found while profiling compile times (apache#24325, apache#24326, apache#24329, apache#24330, apache#24338, apache#24339) — this is the largest remaining item I measured. ## Rationale for this change `datafusion-functions` declares **63 `[[bench]]` targets**. Each one is a separate binary that statically links this crate, arrow and criterion, so building the crate's benchmarks means 63 link steps. Linking, not compiling, is the bulk of it: rebuilding a **single** bench target takes **10.6s**, almost all of it link, while the 63 benchmark files together are only ~10.5k lines of source. This is paid by `cargo bench`, by `cargo build --all-targets`, and by CI's `clippy --all-targets`. ## What changes are included in this PR? The targets are grouped by their `required-features`, which preserves that semantics exactly — a group can only be built when its feature is on, just as each individual bench could before: | target | benches | required-features | |---|---|---| | `string_expressions` | 16 | `["string_expressions"]` | | `math_expressions` | 16 | `["math_expressions"]` | | `unicode_expressions` | 12 | `["unicode_expressions"]` | | `datetime_expressions` | 8 | `["datetime_expressions"]` | | `regex_expressions` | 4 | `["regex_expressions"]` | | `misc` | 4 | none | `crypto`, `encoding` and `dictionary_encoding` stay standalone — they are the only members of their feature groups, so grouping them would buy nothing. Each group lives in its own directory, `benches/<group>/`, with `main.rs` declaring the individual benchmarks as modules and listing their criterion groups in a single `criterion_main!`. Cargo does not auto-discover targets inside those directories, so no `autobenches = false` is needed — which also keeps `cargo machete` working (it stops scanning `benches/` when autodiscovery is disabled). `benches/helper.rs` stays shared at the top level, reached with `#[path = "../helper.rs"]`. **The benchmark code itself is untouched.** There is not a single change to a `bench_function`, `benchmark_group` or `bench_with_input` line anywhere in the diff — git reports every moved file as a 94–99% similarity rename. Per file the change is only: - drop `criterion_main!` — a module cannot define `main` - drop the now-unused `criterion_main` import - drop `extern crate criterion` (a no-op since edition 2018, present in 4 files) - point the four users of `benches/helper.rs` at `crate::helper` ## Are these changes tested? Interleaved with `main` so machine drift cancels out: | `cargo clean -p datafusion-functions` then… | main | this PR | |---|---|---| | `cargo build --benches` | 43.9s / 42.9s | **28.4s / 28.3s** | | `cargo check --benches` | 15.0s / 14.7s | **12.9s / 12.8s** | Every benchmark still runs, and the counts show nothing was dropped: | target | benchmarks (`-- --test`) | |---|---| | `string_expressions` | 252 | | `unicode_expressions` | 251 | | `datetime_expressions` | 103 | | `dictionary_encoding` | 36 | | `regex_expressions` | 27 | | `misc` | 21 | | `encoding` | 9 | | `crypto` | 10 (with `--features crypto_expressions`) | Also clean: `cargo clippy -p datafusion-functions --all-targets`, `cargo fmt --check`, and `cargo machete --with-metadata`. Filtering a single benchmark still works — `cargo bench --bench math_expressions -- power` selects exactly one. `cargo metadata` reports 10 bench targets, against 64 on `main`; both counts include the auto-discovered `helper`, which is unchanged by this PR. ## Are there any user-facing changes? Only for running an individual benchmark. Where you would previously write ``` cargo bench -p datafusion-functions --bench lower ``` you now select the group and filter by name: ``` cargo bench -p datafusion-functions --bench string_expressions -- lower ``` The filter is criterion's own, matching on benchmark id, so it also narrows to a single case within a benchmark. No library changes. If this approach looks right, roughly 100 more bench targets across the other crates could get the same treatment — I did this one crate first so the tradeoff is visible on a real diff before it spreads. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>

rluvaton · 2026-09-02T12:25:03Z

I wasted so much time trying to figure out why in debugger when running test I could not see the variables 😢

setting the env var for this project only is not that convenient unfortunately

## Which issue does this PR close? - Closes None ## Rationale for this change Since apache#24339, the debugging behavior has changed, and variables are no longer included in the debugging output by default. This PR adds a section to the contributor documentation explaining how to enable variable output during debugging. ## What changes are included in this PR? See above. ## What is the testing strategy for this PR? Only doc changes. ## Are there any user-facing changes? No.

Dandandan mentioned this pull request Aug 13, 2026

Building project takes a *long* time (esp compilation time for datafusion core crate) #13814

Closed

Dandandan changed the title ~~build: use line-tables-only debug info in the dev profile~~ perf(build): use line-tables-only debug info in the dev profile Aug 13, 2026

comphead approved these changes Aug 13, 2026

View reviewed changes

Dandandan mentioned this pull request Aug 13, 2026

bench(functions): Improve build time by reducing 63 bench targets into 9 #24342

Merged

Dandandan added this pull request to the merge queue Aug 13, 2026

Merged via the queue into apache:main with commit e76f1af Aug 13, 2026
42 checks passed

Dandandan deleted the perf/dev-debuginfo branch August 13, 2026 19:19

mkleen mentioned this pull request Sep 4, 2026

Add docs section for debugging for contributors #24946

Merged

Navigation Menu

Uh oh!

perf(build): use line-tables-only debug info in the `dev` profile - #24339

perf(build): use line-tables-only debug info in the `dev` profile#24339
Dandandan merged 1 commit into
apache:mainfrom
Dandandan:perf/dev-debuginfo

Dandandan commented Aug 13, 2026 •

edited

Loading

Uh oh!

codecov-commenter commented Aug 13, 2026

Uh oh!

comphead left a comment

Uh oh!

Uh oh!

alamb commented Aug 13, 2026

Uh oh!

rluvaton commented Sep 2, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

Dandandan commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

codecov-commenter commented Aug 13, 2026

Codecov Report

Uh oh!

comphead left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alamb commented Aug 13, 2026

Uh oh!

rluvaton commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Dandandan commented Aug 13, 2026 •

edited

Loading

rluvaton commented Sep 2, 2026 •

edited

Loading