[ disclaimer: I work on the Dart team ]

It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.

Which does 'compile exe' use? Essentially here is what I see -

  $ cat a.dart
  void main() {
  print("hello world");
  }

  $ dart compile exe a.dart
  Info: Compiling with sound null safety
  Generated: /home/x/a.exe
  ~ $ strip a.exe
  ~ $ ./a.exe --version
  Dart SDK version: 2.12.0 (stable) (Thu Feb 25 19:50:53 
  2021 +0100) on "linux_x64"

If I run without --version, it prints the same thing the 'dart' command does.

Thanks - not what I'd expect, but I can repro. Bug filed here:

https://github.com/dart-lang/sdk/issues/45197

It is AOT though. If you time `dart a.dart` vs `./a.exe` (pre strip :-), the latter should be considerably faster.

[I work on Dart VM team]

`dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code.

The approach is not pretty but was chosen as an implementation shortcut.

That's why `strip` does not actually do good things to the binary.

There is no reason to run `strip` on such binaries - because they don't contain anything strippable.

Thanks. Also noting that upx has the same behavior.

I didn't inspect the binaries, just try to see how/if they compress.

We are planning to fix it some time in the future, we really only expected moderate usage of `dart2native` and only on Linux. Turns out that there is demand for using it all over the place, which includes Mac and Windows and requires things like signing support... And to make executable signable we need to make them real Mach-O / PE executables and not weird concatenations of bytes.