-
Notifications
You must be signed in to change notification settings - Fork 232
Big perf difference between running Dart app via pub global activate, or pub run #1349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think this is the command: https://github.com/flutter/engine/blob/55c6cb7efedc1f16cd31d1fb654aabfd0ca24927/sky/packages/sky/bin/flutter.dart cc @abarth |
You're not doing anything wrong; there are just different constraints in these two cases that give rise to different performance. When you run a globally-activated application using its named executable, most of the time it's very lightweight: it doesn't invoke When you run a dependency package, on the other hand, it does go through pub (which happens any time you type There's some work we can do to make this better. #1011 should help, for example. But a lot of it is just very small stuff that's difficult to avoid or optimize. We could theoretically add some logic to the pub wrapper in the SDK to invoke the executable directly, but that would be a lot of logic written in bash and batch and I certainly don't have the shell language expertise to do it transparently. I think the best solution here long-term will be to add support for ahead-of-time compilation to the Dart VM (something that's been talked about before). This will (presumably) allow both pub and the dependency's executable to start up much faster. |
Thanks for the thorough explanation! I wrote a small "what's the fastest path" script that doesn't the basics: figures out what package you are talking about, finds the bin directory, creates the right path, and spawns a process, and runs a script that just prints three lines. It's 0.241s on my mac:
Here's the script:
Of course, this is cutting a ton of corners because this isn't pub, just a very specific script. Not sure we'll ever get much faster than that, in the most bestest case. UNLESS... when installing a dependency, couldn't pub put snapshots of my dependencies into a location relative to my app? Which, I just looked, and it did!
Running that takes only:
Which, I dare say, is pretty dang good. Plus, it has the bonus that I don't need to manually manage my package-root (presumably, it would use a .packages). It seems like we're close to giving our users a very fast experience. If we let them run the snapshots from the .pub dir (and/or, exposed those a little more) they would be really happy. Has anyone thought of doing that? |
We do run snapshots from the
We shouldn't get complacent; 90ms is actually pretty huge for a script that does practically nothing. For comparison, a script that does the same thing written in Ruby—not a language known for its speed—takes about 25ms on my machine* with no snapshotting at all. *: I also checked a snapshotted Dart executable on my machine, and it takes about the same amount of time that it does on yours. |
True, but I wonder if our case (simply run this bin that came from this dependency that's NOT a path dep) is a common case where we can short-circuit to the fast path (run the snapshot). That is, I think we could tell our developers:
Granted, that's a long command line and pretty gross, but it's fast. Of course, it would be better if pub put a wrapper script in my project, similar to the way it does during pub global activate. That would be great.
That might be true, but that might the fastest way to run Dart app now (apparently?). We should definitely make it faster, though.
Yup, me too.
Also, FWIW, running without a snapshot isn't much faster for this very small script:
Talking to Ivan, that's expected.. the size of the script is so small, snapshots don't buy you anything here. |
Users definitely shouldn't be running stuff directly from Is performance here a significant problem? If so, we should allocate resources to solve it properly rather than asking users to work around it. Do we have anyone on the team with strong Bash and especially Windows Batch skills who can work with me to avoid invoking pub entirely if a snapshot exists and is up-to-date? If we do start working on this, I know up front that we'll need dart-lang/sdk#20802 in order to make it work. |
Our users believe it is. It's not a P0 blocker, because we're still making progress, but we're not comfortable with this performance for our users (for a 1.0 product... for a beta product, it might be fine).
This is, I believe, exactly the script that That would be nice, but it doesn't appear to be a requirement. Our scripts generated by May I suggest that we re-open and mark as "help wanted". We can clearly do better with our performance for running scripts that come from dependencies. Maybe we can ask others to help here. |
Maybe we need a
Then |
Yup, that's what I'm thinking. I like that option, because I think we care steal---er, repurpose a lot from the |
The caching behavior with For In addition, We could do something like @abarth suggests and write local scripts to disk, but this has a few problems. One of the biggest is just that it's ugly; it's generally bad form for a tool to incidentally write a bunch of extra user-visible files to disk, and we've heard consistently bad feedback about pub in particular doing so with This is why I say that if we want to solve this, we should commit the resources to solve it properly—finding some intermediate way of re-using the |
Thank you for the detailed analysis. I would like to reopen this because we would like to see improved performance for the common-case of May I please reopen? |
This issue doesn't doesn't describe a solution for the performance, so I'd rather not reopen it. If you'd like to open a new issue for making |
I was under the impression that I shouldn't be filing issues for solutions (that would presume too much), instead I should be filing issues that describe problems that users are having. If you want me to file a request for a specific technical solution, I can do that, but I would encourage that description of a technical solution to come from our engineers. |
Okay, I'll file an issue. |
Thanks very much! On Mon, Oct 26, 2015 at 3:28 PM, Natalie Weizenbaum <
|
I filed this as dart-lang/sdk#24736 (against the SDK since that's where the wrapper scripts live). |
Hi! We'd like to start using pub run to launch our scripts from within our app, but it seems much slower than scripts launched after pub global activate. The startup perf is enough for us to wonder if we're doing something wrong, or if there's a bug.
tldr: app runs in 1 sec via pub run, and 0.3 seconds after pub global activate.
Here are the scenarios:
A) add
flutter: any
to an empty pubspec, runpub get
, then runpub run flutter list --help
B)
pub global activate flutter
, then runflutter list --help
Results from scenario A:
Results from scenario B:
Perf is definitely a feature for us. Any advice on how to get the
pub run
case to be as fast as thepub global activate
case, that would be a big help. We'd really like to get to a single package that contains our libraries and tools, but the startup time ofpub run flutter --list
is prohibitive.Thanks for any advice!
The text was updated successfully, but these errors were encountered: