3X speedup is a definite improvement. I don't use rust regularly, so have been relying on community news for updates and while they have mentioned planned work to increase compilation speed a few times they haven't really talked about any landing (that I saw anyways).
Also cold start speed is not really what I care about. I am more concerned with compiler speed while working and running tests. I find that if a language compiler is to slow it breaks flow while testing changes. I haven't seen much mention of the improvements the incremental compiler gives in a while. Last I read was the 2017 blog post [1] during beta and it only showed modest improvements and more recently I only see talk of how it still needs a lot of work [2].
Incremental compilation was a big improvement over the status quo.
I don't follow compiler performance developments. I'm just responding to clarify that there has been performance improvements. They have likely just built up over time. I don't think there was any one specific change that dramatically improved things.
I don't know about that specific measurement, but memory usage of the Rust compiler has not doubled in general. If it did, we'd notice immediately, as the script crate in Servo would probably OOM.
I wouldn't be surprised if it was due to paralellism, e.g., compiling multiple code units in parallel or even better parallelism at the Cargo level. My stat is just the maximum memory usage reported at any point in time. But that's just a guess. ripgrep itself uses more memory when using parallelism, just because of having more buffers.
We can only speculate about the lower bounds of compile times, but making things faster takes a lot of work. Rustc is a huge codebase, and making general leaps requires large architectural changes. We’ll just keep chipping away. It’ll take some time.
This is only for debug builds though, cranelift. Isn't going to offer good enough performance for a release mode binary anytime soon (and probably never will).
If Cranelift makes debug builds much faster, then that's still a huge win. In my line of work, I do tend to compile things in release mode a lot purely because I often need to debug performance related problems, and for that, debug mode doesn't work. However, most of the test suites in my crates are built and run in debug mode. For example, the test suite for regex-syntax is fairly large, and it can take several seconds to build after making a change. Incremental compilation helped a lot with this, but there's still an annoying waiting period to run the tests. I'd be very happy to see Cranelift reducing the time it takes to run tests.
I 100% agree with you that Cranelift is a big deal (Last year I had to change my desktop CPU just to be able to build, in a reasonable amount of time in debug mode, the Rust project I'm working on − ok my CPU was still a Core 2 Duo at this point).
Even for things where debug mode is too slow, Cranelift could be a game changer since it promises to produce more performant binaries than LLVM in debug mode (Idk if it will be fast enough for you use-cases though).
I just wanted to point out that Cranelift won't solve the compile-time issue all by itself.
I think that's likely. async/await doesn't appear to map directly onto traditional OO GUI framework callbacks well, just like rust doesn't tend to map well to traditional OO. I believe that async/await will open up new architectural patterns that should be as ergonomic as traditional OO callbacks for GUIs. But these won't map well to existing code or existing frameworks.
There have been attempts, like relm, to map futures onto GTK. That means it would work with async/await too, as they’re fundamentally sugar for futures.
Even those are basically Relm components that happen to render via GTK. You can't really import a plain `GObject` and implement a traditional `fn on_click()` without having to worry about internal mutability and the associated borrow checking complexities.
Compile speed, not compiling the same dependencies all over the time.
Many commercial use cases require distribution of binary libraries, Rust community might care about winning those customers, or just let them go and leave them to keep using the languages that fulfil such use cases.
> Compile speed, not compiling the same dependencies all over the time.
Sounds like caching these would be a simpler but solution.
> Many commercial use cases require distribution of binary libraries
[...]
Good use case, and in this case another cache would solve the issue as well. Defining a protocol for binary caches and being able to add your own could solve this very well. The same solution could help solve the previous one too.
BTW, if you are in either case, have you looked into Nipxkgs[1]? They might be able to do both, the basic capabilities are there, not sure if the Rust infrastructure[2] already provides it.
And if you have to drop down to looking at the disassembly, distributing binaries helps ensure everyone's looking at the same disassembly. Reasons for this include investigating codegen bugs, figuring out optimization issues, ensuring functions involved in cryptography aren't leaking information through timing side channels, etc...
