Moving a crate changes the generated code?

I recently made a change to my embedded Rust audio project -- simply moving one of my crates up one directory within the project -- no other changes to the code. I saw that there was a major speed hit -- enough to cause audio dropouts. I looked at the generated assembly, and I can't really read it but it does seem like different assembly is generated for some of the code, including within (for example) the alloc crate.

My question is kind of vague and open-ended, but it's this: what possible reasons could there be for this code to produce a different binary just because it's in a different location relative to the other crates in the project?

Should I just chalk it up to "the optimizer/inliner has heuristics about how hard to work, and could be affected by some path names being slightly shorter"? Or are there possibly other mysteries involved?

Is it all in one workspace?

1 Like

I think I'm not using workspaces -- unless I am using them without realizing it. Would setting up a workspace be a good idea? (Note: Rust newbie.)

I'm wondering how workspaces could affect this. I could see how, if there's some kind of cross-module optimization, and workspaces affects how many codegen units there are, that could definitely have an effect. Is that what you mean?

Is there a cargo.toml file at the root of your project along with individual cargo.toml files for each crate?

(Given the fact you don't know what a workspace is, I suspect the answer is "no".)

1 Like

Indeed, there is not. Would I have more predictable results if I did organize it into a workspace?

No; but you might see different results if at one point the code was in a workspace and at another it was not (because workspaces share Cargo features and compilation options).

1 Like

In this project, I have never used a workspace; the only thing that I am changing is moving a directory up one level. It's reproducible -- I can build both versions and see the significant speed change, and see differents in the assembly.

I wonder if there is some way to dump info about what the optimizer is doing, to see if it's something like that.

Could there be a .cargo/config at one of the locations that isn't being picked up at the other or some such?

1 Like

I wonder if there is some way to dump info about what the optimizer is doing, to see if it's something like that.

There are various unstable options to inspect compiler behavior, but first let's look at how the compiler is being run. If you run cargo build --verbose (or whatever command with --verbose), Cargo will print the full rustc command line it runs. Then you can compare the difference from the two cases.

I imagine it's possible that there is in fact nothing different other than the paths, and the reason for the different output is that having different paths perturbs some hash function's output and thus the order the optimizer looks at things, leading to different conclusions. But hopefully there's something more definite to find.

2 Likes

I don't have any local .cargo directories.

I'll try this.