3 ms·

I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x6

I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x64, ready to run. I built in release mode with publish trimmed, and trim mode set to link. The final size of the binary is 24.6 MB (not counting CLR DLLs), with a build time of 23.2[1] seconds. I also have a Rust version of the project. 710 lines of Rust[0], 128 total dependencies in the tree, building in release mode with the MSVC Windows compiler. Final size of the binary is 2.29 MB, build time of 22.2[1] seconds. Things are not great when your build times rival Rust's, and the output is slower and an order of magnitude bigger. [0] Note that the C# version does have more robust handling when writing its output file than the Rust version, which adds couple dozen lines. Also the style conventions for brackets puts opening brackets on a new line for C#, the same line for Rust. [1] Measured with hyperfine configured to run "dotnet clean -c Release" and "cargo clean" before each run.

e12e 5y ago
> not counting CLR DLLs Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? How about linux/Mac targets? I think 20-30MB is quite good - puts it in the ballbark of golang. 2MB+ for rust actually sounds a bit big -that's stripped?
- Measter 5y ago
  > > not counting CLR DLLs > Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? Note that this is a stand-alone build; it doesn't require the runtime to be installed. With that in mind, you're right they should be included, which would increase the build size by 8.3 MB. > How about linux/Mac targets? I can't build a Mac target because I don't have a Mac. I just built for a linux-x64 target in WSL, and the resulting binary is 35.0 MB. The Linux build looks like it's packaged the CLR into the main binary instead of keeping them separate, which would account for the greater size. I did do a benchmark with hyperfine, which gave a 25.5 second build time. However, this is on WSL1 building off and on to an NTFS drive, which has known performance issues. > I think 20-30MB is quite good - puts it in the ballbark of golang. I've never used Go, but my understanding is that the Go compiler is very fast but doesn't do as much in the way of optimizations. If that's the case, having a larger and slower binary compared to Rust would be expected before you get to the packaged runtime. The issue I'm taking here is that doing a trimmed dotnet build is (in this case) giving the same build time as Rust, but is only doing some AoT compilation and dead-code elimination. Rust is already doing that in addition to a whole host of other optimizations. From a user perspective, this feels like dotnet is giving me a worse end product for the same time taken. Especially given the Rust version wasn't harder to write than the C# version (in fact, due to bad documentation the C# version was harder). > 2MB+ for rust actually sounds a bit big -that's stripped? No, that is not stripped, and with the standard release profile.
GordonS 5y ago
FWIW, I reckon 25MB forba self-contained build is pretty good! Build times are annoyingly if you use trimming tho, I'll certainly agree there. But Rust is such a very different beast than dotnet, that I'm unconvinced it's a useful comparison; IMO a better comparison would be Golang.

e12e 5y ago

> not counting CLR DLLs Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? How about linux/Mac targets? I think 20-30MB is quite good - puts it in the ballbark of golang. 2MB+ for rust actually sounds a bit big -that's stripped?

Measter 5y ago
> > not counting CLR DLLs > Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? Note that this is a stand-alone build; it doesn't require the runtime to be installed. With that in mind, you're right they should be included, which would increase the build size by 8.3 MB. > How about linux/Mac targets? I can't build a Mac target because I don't have a Mac. I just built for a linux-x64 target in WSL, and the resulting binary is 35.0 MB. The Linux build looks like it's packaged the CLR into the main binary instead of keeping them separate, which would account for the greater size. I did do a benchmark with hyperfine, which gave a 25.5 second build time. However, this is on WSL1 building off and on to an NTFS drive, which has known performance issues. > I think 20-30MB is quite good - puts it in the ballbark of golang. I've never used Go, but my understanding is that the Go compiler is very fast but doesn't do as much in the way of optimizations. If that's the case, having a larger and slower binary compared to Rust would be expected before you get to the packaged runtime. The issue I'm taking here is that doing a trimmed dotnet build is (in this case) giving the same build time as Rust, but is only doing some AoT compilation and dead-code elimination. Rust is already doing that in addition to a whole host of other optimizations. From a user perspective, this feels like dotnet is giving me a worse end product for the same time taken. Especially given the Rust version wasn't harder to write than the C# version (in fact, due to bad documentation the C# version was harder). > 2MB+ for rust actually sounds a bit big -that's stripped? No, that is not stripped, and with the standard release profile.

GordonS 5y ago

FWIW, I reckon 25MB forba self-contained build is pretty good! Build times are annoyingly if you use trimming tho, I'll certainly agree there. But Rust is such a very different beast than dotnet, that I'm unconvinced it's a useful comparison; IMO a better comparison would be Golang.