3 ms·

This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. Anyone who doesn't know about

This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. Anyone who doesn't know about many of these tools will probably find them useful (or at least useful to know that they exist) in the future. Besides, for iteration people are probably in debug, not release mode, which the article mentions is initially 19s vs 2m+. As far as I can see the main conclusion seems to be that there was a compiler regression causing the issues, which is fixed in nightly. I don't think many users would need to go through these steps to diagnose the problem beyond "wait for a newer compiler release". In general I don't think being slightly slower in a systems language in cases where you've explicitly asked for full optimisations is that much of a problem when there are simple ways to mitigate the feedback loop (e.g. debug compilations). Would I like these things to be faster? Sure. But with the size of the rust projects I use, it's not noticeable slower than the large established C++ projects I have to deal with (that aren't tuned for compilation speed).

ithkuil 5y ago
Rust debug builds are also unbearably slow. I wouldn't complain that much if it was just a problems of having full optimizations on
- singron 5y ago
  For perf sensitive projects, I set opt-level=1 in debug for at least the dependencies. Edit: I realized you might have meant that debug compiles still take a long time. In that case, obviously this won't help.
MuffinFlavored 5y ago
> This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. I'd argue that when it comes to doing work, I only want to deep-dive into my code. Not third party libraries that "vow" to have been tested + performant, let alone the language/build tools themselves.
- mustache_kimono 5y ago
  I thought this level of entitlement was restricted to open source users, not devs. AFAIK Rust never promised anything re: the compile-time performance of its standard library, and I know of no 3rd party library that does. You link in a 3rd party library, then that's your code now for better or for worse.
- misnome 5y ago
  I'd be interested to hear what system/field/language you use with compilers that come with guarantees that they will never, ever introduce performance regressions for compile times under any circumstances (presumably with a hefty SLA to match), and where the addition of e.g. an extra innocuous header by some other part of your team will never never ever introduce unexpected nonlinear compile times that require investigations of what the compiler is spending times on. I suspect this only applies to an extremely small portion of real world code and projects (direct hand optimised asm, perhaps something like forth?) As far as I am aware the only "guarantees" (interpreting "vow" to mean this) with rust are that edition-bound code will continue to compile correctly, modulo bugs which may be introduced/need fixing. Of course, it feels like rust could do better, the reputation it has hasn't come from nowhere, but, personally, it's a far cry from e.g. the projects I work on, where we are mandated (by inter-company politics) to use a custom SCons atrocity on C++ that takes two minutes to run a no-op build.
  - pjmlp 5y ago
    Naturally having scons written in Python has nothing to do with it.

ithkuil 5y ago

Rust debug builds are also unbearably slow. I wouldn't complain that much if it was just a problems of having full optimizations on

singron 5y ago
For perf sensitive projects, I set opt-level=1 in debug for at least the dependencies. Edit: I realized you might have meant that debug compiles still take a long time. In that case, obviously this won't help.

MuffinFlavored 5y ago

> This is more of a step-by-step deep-dive into the ways to profile, diagnose and work through the timing and performance problems. I'd argue that when it comes to doing work, I only want to deep-dive into my code. Not third party libraries that "vow" to have been tested + performant, let alone the language/build tools themselves.

mustache_kimono 5y ago
I thought this level of entitlement was restricted to open source users, not devs. AFAIK Rust never promised anything re: the compile-time performance of its standard library, and I know of no 3rd party library that does. You link in a 3rd party library, then that's your code now for better or for worse.
misnome 5y ago
I'd be interested to hear what system/field/language you use with compilers that come with guarantees that they will never, ever introduce performance regressions for compile times under any circumstances (presumably with a hefty SLA to match), and where the addition of e.g. an extra innocuous header by some other part of your team will never never ever introduce unexpected nonlinear compile times that require investigations of what the compiler is spending times on. I suspect this only applies to an extremely small portion of real world code and projects (direct hand optimised asm, perhaps something like forth?) As far as I am aware the only "guarantees" (interpreting "vow" to mean this) with rust are that edition-bound code will continue to compile correctly, modulo bugs which may be introduced/need fixing. Of course, it feels like rust could do better, the reputation it has hasn't come from nowhere, but, personally, it's a far cry from e.g. the projects I work on, where we are mandated (by inter-company politics) to use a custom SCons atrocity on C++ that takes two minutes to run a no-op build.
- pjmlp 5y ago
  Naturally having scons written in Python has nothing to do with it.