cargo: emit less debug info, and compile all deps in optimized mode

[thoughtpolice]

See commit messages for details.

[yuja]

I'm conservative about changing the default build profile, but I'm not against this change if people like it.

Regarding debug = "line-tables-only", I don't think disk size is so important. The target directory will grow indefinitely anyway. If it breaks gdb, I would vote against it.

[martinvonz]

Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode. What do you think? Is that possible/easy to configure?

[yuja]

Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode.

fwiw, I tried something like that for "pest", but it didn't help much. That's probably because the parsing code is generated by proc macro.

[thoughtpolice]

Since dependencies rarely change, I would prefer to compile all dependencies in optimized mode and compile only the crates in the repo in debug mode. What do you think? Is that possible/easy to configure?

Yes, that's exactly what the first change will do. The semantics are a bit weird but make sense; [profile.dev.package."*"] applies to all dependencies, while [profile.dev] will only apply to crates in the given repository. (I verfied this with --verbose where you can see opt-level=3 getting passed to dependent crates, but not jj crates.) So, this is exactly what we want. :)

[thoughtpolice]

The target directory will grow indefinitely anyway.

Yes, but anything to help fight off the nearly infinite disk space usage is nice IMO. Something is much better than nothing. :) Also, writing significantly less debug info does help compile times, though the opt-level=3 change offsets that a bit.

Frankly I would be much happier if Cargo could actually GC the target directory as a first-class feature, but that's a bit of a pipe dream, at least for now...

If it breaks gdb, I would vote against it.

Do you often use GDB for debugging? I admit, I nearly never use it for type-safe languages like Rust, but I guess that's maybe just because of my history in other compiled languages where I didn't need them or have DWARF symbols, so I was just stuck with fresh assembly code. Anything unsafe I just isolate and bang on and fuzz endlessly, manually. That's a bit "Back in my day I walked uphill both ways to get to school" though, so I get that it's not a great argument.

TBH, I've wanted to have specific settings of mine put in .cargo/config.toml before, but I don't want to force them on everyone else on the team. Maybe we could instead just have a few different "example files" under .cargo/, ignore the default .cargo/config.toml, and let people symlink their configuration of choice? Then we could have a .cargo/full-debug.toml that you can symlink into place. That might be nice.

[martinvonz]

Yes, that's exactly what the first change will do.

Heh, I somehow missed that. Sorry.

[martinvonz]

I think this is what makes it so much slower. I agree with Yuya that the size of the binary is not important to optimize for.

I'll happily approve a PR that just sets opt-level = 3 for all dependencies and nothing else (but it's a significant change, so you might want to wait to hear from others too).

[thoughtpolice]

FWIW, codegen-units=1 has nearly no impact at all on compile times (or at least the fluxuations are minor), and also has almost no (repeatably measurable) impact on runtime for me, either. I included it for a more pedestrian reason: so that the dependencies in the development build more closely match the dependencies in the release build, where we do set that option. But I can drop it too, if we'd like.

[thoughtpolice]

And also, I want to be clear it is not the size of the final binaries that I am worried about with the line-tables-only change. It is the size of every intermediate artifact ever compiled — by rust-analyzer, by running nextest, from dependabot updates, etc. My development machine for jj has 1TB of space, but it's absurd that Cargo can eat almost +100GiB every two weeks for a single project. This will continue to get worse as we pile in more crates (but that's another discussion). I think that just building once in release profile and once in the dev profile will put you at 10GB of disk space usage... It piles up very fast.

There are other factors here, for example my machine uses mold for linking, but I suspect that this change would have a positive impact on non-mold users (where there is no parallelism, and debuginfo tends to have a disproportionate affect on link time). I also suspect that on an actual HDD where write times are 100x slower and random reads are slow and sequential will probably see improvements, too. But those are just speculation; I haven't tested them, though I'm happy to.

[martinvonz]

On my machine, codegen-units=1 on dev deps increases the build time from about 50s to about 60s. Since dependencies are rarely recompiled, I'm fine with either.

[PhilipMetzger]

I'm fine with this, even if normal builds take a bit longer. The linetables change is nice for development but makes it harder to diagnose issues for users, so let's hope our dependencies don't break to much 🙏 .

[yuja]

Do you often use GDB for debugging?

Not often, but I occasionally do. Last time I used gdb was to debug libgit2 behavior. If I were new to jj codebase, and debugger didn't work, I would be confused.

[emesterhazy]

+1 for the notion that it would be nice if debuggers still worked after this change. For what it's worth though, I'd also be fine if we just added a doc that discussed how to get the debugger working properly. It's not a simple as setting a breakpoint in an IDE since the tests run the CLI in a subprocess, so if the user also needs to build with a different profile that seems ok as long as it's documented with instructions.