Slow startup time when using symbolic link to dart executable

[rbehrends]

Dart VM startup time is considerably slower when the executable is not directly in the path, but when it is instead linked symbolically (as is the case with Homebrew installations, for example). Example:

$ unzip -q dartsdk-macos-x64-release.zip
$ ln -s dart-sdk/bin/dart .
$ ./dart --version
Dart VM version: 2.1.0 (Tue Nov 13 18:22:02 2018 +0100) on "macos_x64"
$ cat >test.dart
void main() {}
$ time ./dart test.dart
./dart test.dart  0.82s user 0.11s system 148% cpu 0.626 total
$ time ./dart-sdk/bin/dart test.dart
./dart-sdk/bin/dart test.dart  0.31s user 0.08s system 178% cpu 0.219 total
$ time ./dart test.dart             
./dart test.dart  0.82s user 0.10s system 148% cpu 0.626 total
$ time ./dart-sdk/bin/dart test.dart
./dart-sdk/bin/dart test.dart  0.32s user 0.07s system 177% cpu 0.221 total

Observed with Dart 2.1.0 on macOS, but it also happens on Linux and also with Dart 2.0.0. A workaround is to use a link to a shell script that exec's dart with its real path. It does not seem to matter whether the symbolic link is a relative or an absolute path.

[zguo93]

The root cause is that kernel service snapshot is not found. The vm will check whether .snapshot sits in the same folder with executable file. If nothing found, it will call kernel_service, which takes longer time to compile.
Solution: add --dfe= path/to/kernel-service.dart.snapshot if using symbolic link.

[knopp]

Maybe the vm could resolve the symlink and then check?

This is a rather bad user experience by default. In my case on some script running just "dart" (/usr/local/bin/dart) takes over 5 seconds to launch a script instead of 1.5 second when lauching the actual executable from libexec.

Without this issue I'd never have guessed that running the actual exectuable would speed things so significantly.

[knopp]

@zguo93, perhaps this issue could be reconsidered?

[zichangg]

Thanks for comment. That's my old account name.
I think this looks good to me. @a-siva Wdyt? Any concern?

[a-siva]

Agree we could resolve the sym link and check.