Skip to content
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

iterate on the kernel-based summary format #31704

Open
sigmundch opened this issue Dec 21, 2017 · 1 comment
Open

iterate on the kernel-based summary format #31704

sigmundch opened this issue Dec 21, 2017 · 1 comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. customer-analyzer customer-bazel customer-dev-compiler front-end-kernel

Comments

@sigmundch
Copy link
Member

This meta bug is to track some requirements we have on kernel-based summaries, so we can iterate on their design.

At this time we are using kernel outlines as a summary format for analyzer, bazel, and ddc. Similar to how we have a special format to support hot-reload, we believe we need some special adjustments for the summary format as well.

For bazel, the main requirement is scalability on modular compiles, ensure that the output doesn't change if the sources compiled into a summary didn't change or if the only changes didn't affect the public API of the module (changes within method bodies, or whitespace changes).

I figure we can use this bug to keep tracking other requirements from other clients.

/cc @peter-ahe-google

@sigmundch sigmundch added area-front-end Use area-front-end for front end / CFE / kernel format related issues. area-kernel customer-analyzer customer-bazel customer-dev-compiler labels Dec 21, 2017
@sigmundch
Copy link
Member Author

More details on bazel: today bazel builds analyzer summaries by passing transitive dependencies to the each target. To scale this requires that data is not duplicated on every target (which outlines do). So one proposed solution is to truncate summaries (similar to how we truncate hot-reload deltas). I tried an experiment doing this and saw a 5x speed improvement in a small app, and reduced the size of the generated code dramatically (consider that the platform outline is 3M, so every intermediate package had a .dill file of at least 3M).

An alternative solution is to tree-shake summaries based on reachability, and change the bazel architecture to stop passing transitive dependencies instead (since the necessary transitive deps could be passed on within the summary). After our experiment using tree-shaking in kernel-driver, I'm not convinced of this approach, and I would rather continue with the existing bazel architecture until we swap out the summary format. Later we can revisit this and make it better.

whesse pushed a commit that referenced this issue Dec 21, 2017
Also remove "trimDependencies".

For context: see issue #31704 (#31704)

Change-Id: Iedce40fac9ed974850b41145e531d08aeccee87b
Reviewed-on: https://dart-review.googlesource.com/30963
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
@kmillikin kmillikin added area-front-end Use area-front-end for front end / CFE / kernel format related issues. front-end-kernel and removed area-front-end Use area-front-end for front end / CFE / kernel format related issues. area-kernel labels Sep 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. customer-analyzer customer-bazel customer-dev-compiler front-end-kernel
Projects
None yet
Development

No branches or pull requests

2 participants