[RESPONDED] Compiling cargo crates is unusually slow on the 13" 7840U

I have found Rust compilation (Via Cargo) on the Framework 13 AMD 7840U is incredibly slow, what used to take mere minutes on an 11th Gen Intel i7 is now taking around 4–6 hours.

I can’t seem to figure out the cause. Even with tuned in latency-performance configuration and cores hitting 4.2GHz. It however isn’t using more than 100% of a single core at a time. It is however using all cores during compile.

During compilation, there’s no slow down on the system running any day to day tasks. It seems to be limited in how fast it can munch through the compilation, the CPU temp is usually hitting 90*C. The old intel Laptop had far worse cooling than this Framework, so I’m a little confused.

I’ve noticed this during builds of alacritty, eza and spotify_player.

I’m running Debian Sid, with the latest updates, using only 64bit packages. On Kernel ‘6.7.9-amd64’. I have also installed all AMD firmware that’s listed on the Debian wiki. The BIOS is on V03.03b. I have 16GB of RAM, 2GB reserved as VRAM.

Any help will be useful.


Hello fellow Rustacean!!
Using rustc, does the same behavior appear?
I haven’t seen this issue before…

1 Like

Do you have a good example I could use to compile in cargo and then rustc to see if it also has the issue?

1 Like

4-6 hours sounds like either:

  1. Thermal throttling. If you’re confident the CPU is running at a reasonable clock though, you can probably rule this out.
  2. Swapping. Is your RAM getting maxed out, causing your system to rely on swap?
  3. Some kinda virtualization gone wrong. You’re not compiling inside docker buildx or anything like that right? I’ve gotten 6 hour compile times in the past when compiling for ARM with docker buildx because of the qemu overhead.

We do not test against Debian. I agree with others, this is likely thermal throttling, but would want to see it against a fully updated Fedora 39 install to be sure as I have not had issues with cargo on it.

1 Like

Thermal throttling seems unlikely to me. Usage would still be pinned even if it was throttling, and 4-6 hours seems like a lot. You don’t have this issue with other intensive workloads right?
My intuition says there’s just something wrong with your cargo configuration or rust on your system. As Matt suggested, live booting a USB to sanity check may be helpful!

1 Like

I built eza in a Fedora 39 live environment, and it built in barely 15 seconds. So it’s not a hardware issue.


No, I’m not compiling inside any virtualisation and swap isn’t being used, RAM is showing 5GB free while compiling.

I’d also think thermal throttling, but then why would it be fine under fedora?

All cargo configurations were default, but during testing I’ve added this to .cargo/config.toml

jobs = 16

browser = "firefox-nightly"

quiet = false          # whether cargo output is quiet
verbose = true         # whether cargo provides verbose output

No issues with other intensive workloads, I’ve been gaming in Cyberpunk and Metro Exodus without issues. All other system functions work as expected.

A few things to check on the software side then:

  • What’s your default target for rustup? Should be stable-x86_64-unknown-linux-gnu.
  • What linker are you using? Should be x86_64-linux-gnu-gcc.

Maybe there’s something wonky on debian causing rustup to set those wrong. Just spitballing 'cause if it’s not thermal throttling, swap, or virtualization then I’m running out of good ideas :sweat_smile:


Indeed, a very strange issue.

I can suggest you doing rustup update to see if it would make any difference. It could be that on the older machine you used different version of rustc.

Also it is worth checking iostat so see what’s happening, because sometimes iowait can be misinterpreted as 100% CPU load when in fact it’s busy waiting for data. That can also explain why it feels responsive under normal load, since typical apps do not yield multi-gigabyte writes within short amount of time.

It could be that you have degraded FS and/or SSD that sabotages your I/O.

~► rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/tom/.rustup

stable-x86_64-unknown-linux-gnu (default)
rustc 1.77.0 (aedd173a2 2024-03-17)
1 Like

OK Super weird, nothing is showing in iotop for the builds. I’m currently compiling both tealdeer and bat and they aren’t showing. pretty much just firefox, thunderbird and xorg pop up.

While this is happening I’m also noticing actions like archiving in thunderbird is hanging and opening a screenshot in gimp is super slow. I think you might be right in it being an SSD issue. I’ll run some tests.

When not compiling, I ran a read/write test via dd. This seems to be fine. It’s a CT1000P5PSSD8

~► sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync        
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.509903 s, 2.1 GB/s
~► dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.0656505 s, 16.4 GB/s
~► sudo /sbin/sysctl -w vm.drop_caches=3
Place your finger on the fingerprint reader
vm.drop_caches = 3
~► dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.471274 s, 2.3 GB/s

After doing this everything is running great!

I think it was a caching issue, as all I changed on the system was

sudo /sbin/sysctl -w vm.drop_caches=3

What a palava! Thanks guys.

I would still blame SSD, though. By dropping the caches you just swept the dust under the carpet and the issue would probably re-emerge soon-ish.

1 Like

If I encounter any more issues, I’ll consider the SSD.

OK, coming back to this the next day, I think I’ve found the overarching issue with the compilation, as tweaking it made builds run superfast. It had nothing to do with the SSD itself.

I had Clam On Access scanning /tmp and var/tmp. It was having issues with something I guess and blocking access to files cargo was using. I haven’t looked into logs, and unless someone else encounters this I’m not going to. But I now only have Clam on access scanning my downloads.

Insane speed boost by doing this.

It makes sense as ClamAV was using a lot of resources while building with cargo, should have noticed it sooner.

1 Like