-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
All the major users of getSourceReport
(package:coverage, flutter, google) do something like this:
- Get a list of all the scripts in the isolate (
getScripts
) - Check the script URI vs a filter or set of filters
- Get a source report for each script allowed by the filter
- Combine all the source reports
The number of RPCs this involves leads to performance issues. Coverage can also be gathered for the entire isolate at once, but this leads to a trade off between sending many RPCs vs sending one RPC that returns data we don't care about.
Fortunately, all the filtering that users are doing is of the form:
- If the script URI scheme is not 'package', ignore it
- If the first element of the script path is not in an allow list, ignore it
- Otherwise include it
See the usage of scopedOutput
in package:coverage for an example.
Flutter's test framework is slightly more permissive, and just checks if the script URI contains the project name. But I think in practice this is equivalent to the filter algorithm above. Eg hello_world project has URIs like this: package:hello_world/main.dart
, which would pass the same filter.
So if we add a list of strings to getSourceReport
, and do this filtering in the VM, we can significantly reduce the number of RPCs clients have to do.
See also:
flutter/flutter#100751
flutter/flutter#101383
EDIT: To simplify the implementation, and generalize the use cases, I've changed the semantics to just do essentially urlString.startsWith(filter)
, using the URL of the package/library, not the individual source files. It's still the case that only one of the filters needs to match for the library to be accepted.