This also makes perf_test.dart do something useful. It now executes perf.dart on
a small file from pkg/front_end. This may help to detect early when the
peformance bots will see a failure. I've only tested this in linux, but given
that's the OS of the perf bots, I'm ok skipping this in other OSs.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2677423002 .
This carries a number of benefits:
- It allows the front end to trivially support schemes other than
"file:" (e.g. "http:") by allowing the client to supply a FileSystem
implementation that handles them.
- It is more consistent with the functionality of the ".packages" file
(which allows packages to map to any kind of URI).
- It allows the "bazel root" feature to be rewritten to use a magic
scheme rather than a magic path. (This eliminates concerns about
the magic path overlapping with a user's use case). Note that this
feature has been renamed to "multi root" since it is sufficiently
generic to be applicable to build systems other than Bazel.
- It reduces the risk of forgetting to use the front end's FileSystem
abstraction to access the file system, since the native file system
interfaces do not accept URIs.
R=danrubel@google.com
Review-Url: https://codereview.chromium.org/2614063007 .
I'm happy to split the style/refactorings as separate CLs if you prefer. Here is a summary of the changes:
- update the reported strings to match the names expected by our benchmark runners ("unlinked summaize + parse" => "unlinked_summarize")
- invert the benchmark results (like Paul did in 2551533003)
- stop counting input-size while scanning, count that separately once
- combine the multiple summarization steps into a single function
- clean up the logic that dispatches into each benchmark
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2602003002 .
This CL adds support for using sdk summaries when building kernel using the
front_end entrypoint. I didn't expose this functionality in the dartk binary,
I'm hoping we can delay doing so until we integrate dartk and front_end.
I also switched front_end/tool/perf.dart to use kernel_generator directly.
This makes some observable difference for small scripts, but not so much with large apps like dart2js. Makes sense considering that the sdk is about 2Mb, and dart2js is 6Mb of sources.
The most interesting number I got is building the a library kernel file (not the whole program) for a small hello-world script on a warmed up vm:
no summaries: 500ms
with summaries: 30ms
R=asgerf@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2562923002 .
In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.
dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.
The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.
It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.
In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
Source mapping URIs are not yet affected by this change.
R=kmillikin@google.com
Committed: https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
Review URL: https://codereview.chromium.org/2532053005 .
Reverted: https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
Florian Loitsch