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

Dart's library system impedes code caching #13390

Closed
DartBot opened this issue Sep 18, 2013 · 3 comments
Closed

Dart's library system impedes code caching #13390

DartBot opened this issue Sep 18, 2013 · 3 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Sep 18, 2013

This issue was originally filed by Misko.H...@gmail.com


A typical way to do caching in JS world is to set the URL to be cached forever and to have the URL contain the version number of the source (such as timestamp or SHA). This agressive caching allows the browser to skip the URL fetch and hence improve performance. If the code needs to be updated the version/timestamp/SHA is changed which changes the URL and causes a new fetch and cache. This is an effective way to do caching.

Karma uses this to get its fast turnaround, by caching files aggressively and appending cache busting timestamp. Karma on dart can not perform this caching since there is no way to do cache busting.

In order to do cache busting it must be possible to change the import statement URLs to insert a cache busting token. Since import statements are spread all over the file system there is no central way to manage them and control cache expiry.

Compiling all dart code into single monolithic file (such as dart2dart) only makes this problem worse since if any portion of the codebase changes it is than required to re-download all of the code.

http://karma-runner.github.io/0.10/index.html

@lrhn
Copy link
Member

lrhn commented Sep 19, 2013

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

@gbracha
Copy link
Contributor

gbracha commented Aug 27, 2014

Set owner to @gbracha.
Added Accepted label.

@DartBot DartBot added Type-Enhancement area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels Aug 27, 2014
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Feb 29, 2016
@munificent
Copy link
Member

Cache busting is definitely useful. The fact that imports are spread throughout the source code isn't the biggest problem. It's simple to traverse the import graph and gather them all up.

The nasty problem is that imports can be cyclic in Dart. That makes it very hard to define a stable content hash for a library since it depends on the cache busted IDs of its imports, which may in turn depend back on itself.

I don't think the individual library level is the right granularity for this. Dev_compiler has an explicit "module" layer that groups libraries together into "compilation units" that are explicitly acyclic. If we want to do cache busting, that's where to do it.

Closing this, since it's out of scope for the language itself.

@munificent munificent added the closed-not-planned Closed as we don't intend to take action on the reported issue label Dec 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants