Reduce memory usage when using .dill

[dylanblokhuis]

Not really sure how Dart works internally but is it possible to omit the Dart Frontend compiler by not using "dfe"?

I compiled a version of dart_shared_library by not using dfe.ReadScript if a .dill file was provided and it saved around ~100mb of memory on Windows. See https://github.com/dylanblokhuis/dart_shared_library/blob/94b2912eaa46996ff6ea97877b2856d1d8ff29a7/src/isolate_setup.cpp#L255

[fuzzybinary]

Hey @dylanblokhuis ,

I'll have to look into it. If you're using a .dill, you definitely shouldn't need the DFE, but I believe you might also sacrifice hot reload. This is something I've been looking into for Godot Dart for a bit and unfortunately haven't been able to figure out an answer.

For the time being, I'd rather not omit the DFE completely, as if I do you can't read and the compile the script directly, which was how I wanted this to work instead of having to rely on a separate compile step before launching my target application.

Unfortunately (or fortunately, depending on how you look at it...) it does look like Dart will be separating out the DFE from the backend, so the change you're suggesting may be required at some point.

That said, it's possible I'm over-using the DFE in cases where a .dill is provided. I'd see if the Dart executable does anything to avoid booting the DFE in the case of loading a .dill and follow its example, especially as they continue the separation between dart.exe and dartvm.exe it should be become clearer how to separate the two in this use case.

If you can figure it out, I'm happy to accept a PR!

[dylanblokhuis]

Quick sidenote: Thanks for making this library, I strongly believe Dart is one of the best languages in terms of performance trade-offs and productivity (JIT & HMR in development, AOT in production). Hopefully the Dart maintainers will add an easier way for us to embed Dart in the future!

I'll have to look into it. If you're using a .dill, you definitely shouldn't need the DFE, but I believe you might also sacrifice hot reload. This is something I've been looking into for Godot Dart for a bit and unfortunately haven't been able to figure out an answer.

Wouldn't you want for Godot-Dart to just use a .dill and remove DFE in a release build? No need for hot-reloading when you're shipping a game. Right?

[fuzzybinary]

I strongly believe Dart is one of the best languages in terms of performance trade-offs and productivity

Thanks! I obviously agree!

Wouldn't you want for Godot-Dart to just use a .dill and remove DFE in a release build? No need for hot-reloading when you're shipping a game. Right?

You want hot reload in Godot Dart while you're developing the game.

To be clear, hot reload doesn't actually require the DFE. It's just all attempts I've made to get it to work without the DFE have failed. But so far as I've been able to decipher, Flutter doesn't actually use the DFE in its embedding at all.

The end state of Godot Dart given what I've been seeing from the Dart team and Dart 3.10 is for it to build .dills using the Dart toolchain, not through dart_shared_library, then load them incrementally to achieve hot reload. This is what Flutter does, but following how Flutter does this is a bit daunting, and I haven't been able to get it to work. If I could get it to work, that would mean we could remove the need for the DFE like you said.

This isn't necessarily the perfect state for all my use cases (I'd love to just launch my executable and have it dynamically load Dart Code with Hot Reload....) but it's likely where Dart is going in the future.

[dylanblokhuis]

Sounds like a lot of work to try and figure that out. I'm going to try and see if I can dissect Flutter to remove all code not related to the Dart VM and generate a small flutter_embedder.h

[fuzzybinary]

To be honest, the magic sauce is actually in the flutter_tool code (around here and here), not in its boot of the VM. If you can setup the incremental dill compilation and sync and get that to work with the signal to the kernel to do hot reload, we can probably add flags to dart_shared_library to not boot the DFE (and add instructions to the repo on how to do this effectively).