Deferred parsing for legacy modules

Deferred parsing for legacy modules

This is a nice win for large, internal apps.  Module code is not parsed until accesses via proxy.

R=jmesserly@google.com

Committed: https://github.com/dart-lang/sdk/commit/e011ac789e96395825febca4008d9a6ec95509f9

[vsm, 2017-02-15 19:26:04]

Description was changed from

==========
Deferred parsing for legacy modules
==========

to

==========
Deferred parsing for legacy modules

This is a nice win for large, internal apps.  Module code is not parsed until
accesses via proxy.
==========

[vsm, 2017-02-15 19:29:26]

vsm@google.com changed reviewers:
+ jmesserly@google.com, leafp@google.com

[Jennifer Messerly, 2017-02-15 20:08:50]

So, it looks like this optimization is mutually exclusive with interoperating
with other JS modules. Is that the intent?

Since this relies on proxies, there may be ways we can make this work with real
module formats. I'm not sure if that is something we want to take on at some
point? If so we'd likely need some implementation changes.

That said, if we intend to take on more debt in modules/interop, I can accept
that is a call we may need to make right now.

The code changes LGTM.

https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
File pkg/dev_compiler/lib/src/compiler/module_builder.dart (right):

https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
pkg/dev_compiler/lib/src/compiler/module_builder.dart:145: class
LegacyModuleBuilder extends _ModuleBuilder {
Should we rename this, DeferredModuleBuilder, and change the terminology from
"legal" to "defer" in help and options and docs? 

It seems like this isn't legacy anymore, but a format that is supported because
it offers a unique feature (defer support).

Otherwise, do we intend to offer defer support for other module formats?

https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
pkg/dev_compiler/lib/src/compiler/module_builder.dart:168: 'let # =
dart_library.defer(#, #, function (mod, lib) {'
Does this work for a JavaScript module we import?

are we assuming that DDC won't work be able to interoperate with JavaScript
modules in the future?

[vsm, 2017-02-15 20:29:23]

On 2017/02/15 20:08:50, Jennifer Messerly wrote:
> So, it looks like this optimization is mutually exclusive with interoperating
> with other JS modules. Is that the intent?
> 
> Since this relies on proxies, there may be ways we can make this work with
real
> module formats. I'm not sure if that is something we want to take on at some
> point? If so we'd likely need some implementation changes.
> 
> That said, if we intend to take on more debt in modules/interop, I can accept
> that is a call we may need to make right now.
> 
> The code changes LGTM.
> 
>
https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
> File pkg/dev_compiler/lib/src/compiler/module_builder.dart (right):
> 
>
https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
> pkg/dev_compiler/lib/src/compiler/module_builder.dart:145: class
> LegacyModuleBuilder extends _ModuleBuilder {
> Should we rename this, DeferredModuleBuilder, and change the terminology from
> "legal" to "defer" in help and options and docs? 
> 
> It seems like this isn't legacy anymore, but a format that is supported
because
> it offers a unique feature (defer support).
> 
> Otherwise, do we intend to offer defer support for other module formats?

I would like to consider that.  We may need support in the linking / loading
layer. ( E.g., when webpack does link-time transformation when loading node
modules.)
 
>
https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
> pkg/dev_compiler/lib/src/compiler/module_builder.dart:168: 'let # =
> dart_library.defer(#, #, function (mod, lib) {'
> Does this work for a JavaScript module we import?
> 
> are we assuming that DDC won't work be able to interoperate with JavaScript
> modules in the future?

No.  I've kept these changes to the legacy module.  If handwritten JS uses that
module format, it should just work too.  Since we're using proxies, it should be
invisible for the most part.

[vsm, 2017-02-15 20:32:58]

https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
File pkg/dev_compiler/lib/src/compiler/module_builder.dart (right):

https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
pkg/dev_compiler/lib/src/compiler/module_builder.dart:168: 'let # =
dart_library.defer(#, #, function (mod, lib) {'
On 2017/02/15 20:08:49, Jennifer Messerly wrote:
> Does this work for a JavaScript module we import?
> 
> are we assuming that DDC won't work be able to interoperate with JavaScript
> modules in the future?

If that JS module uses our legacy modules as well, it should work the same,
right?  It doesn't change interop for other module systems.  Similarly, I'm
skipping this for the SDK.

[Jennifer Messerly, 2017-02-15 20:49:07]

On 2017/02/15 20:32:58, vsm wrote:
>
https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
> File pkg/dev_compiler/lib/src/compiler/module_builder.dart (right):
> 
>
https://codereview.chromium.org/2697093002/diff/20001/pkg/dev_compiler/lib/sr...
> pkg/dev_compiler/lib/src/compiler/module_builder.dart:168: 'let # =
> dart_library.defer(#, #, function (mod, lib) {'
> On 2017/02/15 20:08:49, Jennifer Messerly wrote:
> > Does this work for a JavaScript module we import?
> > 
> > are we assuming that DDC won't work be able to interoperate with JavaScript
> > modules in the future?
> 
> If that JS module uses our legacy modules as well, it should work the same,
> right?  It doesn't change interop for other module systems.  Similarly, I'm
> skipping this for the SDK.

ah, I meant a web app that wants to interop with an AMD or CommonJS module. I
think the app developer needs to choose, do I want faster loading or interop
with those modules? but maybe I'm missing something

[Jennifer Messerly, 2017-02-15 20:50:41]

the reason I was hoping we could remove legacy module format soon, is with
legacy format, we can't consume existing JS modules, and the modules we produce
can't be used by the JS ecosystem.

[vsm, 2017-02-16 00:30:27]

Description was changed from

==========
Deferred parsing for legacy modules

This is a nice win for large, internal apps.  Module code is not parsed until
accesses via proxy.
==========

to

==========
Deferred parsing for legacy modules

This is a nice win for large, internal apps.  Module code is not parsed until
accesses via proxy.

R=jmesserly@google.com

Committed:
https://github.com/dart-lang/sdk/commit/e011ac789e96395825febca4008d9a6ec95509f9
==========

[vsm, 2017-02-16 00:30:28]

Committed patchset #2 (id:20001) manually as
e011ac789e96395825febca4008d9a6ec95509f9 (presubmit successful).