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

Adopt dynamic-imports for node module #30685

Closed
jrieken opened this issue Jul 14, 2017 · 6 comments
Closed

Adopt dynamic-imports for node module #30685

jrieken opened this issue Jul 14, 2017 · 6 comments
Assignees
Labels
engineering VS Code - Build / issue tracking / etc. perf
Milestone

Comments

@jrieken
Copy link
Member

jrieken commented Jul 14, 2017

With TypeScript 2.4 we can now use dynamic imports to improve startup performance. The idea is to lazy load certain modules that aren't (always) needed for starting up. Generally, lazy loading requires some amd-bundle-gymnastics but with node-modules everything is easy. The motivation is that 20% of code loading (from cached data) is spend loading node-modules.

To see how long it takes to load a certain module do the following:

  • start code with the --performance flag
  • in code hit F1 and show startup performance
  • below the table with startup times are different sections outlining times to load and execute all modules we have. Look at everything taking 10ms or longer

In short, the idea here to explore using dynamic imports for lazying. Already today this can be done with late require-calls but you lose typing inference with that. Dynamic imports give you both, late and lazy loading and type safety/inference.

Sample times when not having cached data (very first startup, ~200 of 1500ms)

screen shot 2017-07-14 at 11 27 43

Sample times when having cached data (also node modules are cached, ~100 of 500ms)

screen shot 2017-07-14 at 11 29 04

@jrieken jrieken added engineering VS Code - Build / issue tracking / etc. perf labels Jul 14, 2017
@jrieken jrieken self-assigned this Jul 14, 2017
@jrieken
Copy link
Member Author

jrieken commented Jul 14, 2017

cc @Tyriar for evaluating what it means to load xterm only when needed.

@Tyriar Tyriar self-assigned this Jul 14, 2017
Tyriar added a commit that referenced this issue Jul 14, 2017
@Tyriar
Copy link
Member

Tyriar commented Jul 14, 2017

@jrieken 6d71f77 removes it completely from startup, just need to work out how to pull in types without requiring the code, while still keeping them inside xterm.d.ts.

screen shot 2017-07-14 at 10 02 18 am

@jrieken
Copy link
Member Author

jrieken commented Jul 14, 2017

Great. For having types without loading you can use some on-thin-ice-trick which is keeping the import xyzzy from 'xterm'-statement globally but making sure you reference nothing that exists at runtime. So, if you only reference interfaces and purely-declared-things there will be no global dependency in the emitted JS code. A proper variant of that might be have two d.ts-files, one for runtime types and one for interfaces et al.

@Tyriar
Copy link
Member

Tyriar commented Jul 14, 2017

Actually in the process of doing that exact thing microsoft/TypeScript#15902, getting a weird error though:

screen shot 2017-07-14 at 10 06 41 am

A proper variant of that might be have two d.ts-files

Soon the types will be handles entirely by the module, it would be a shame to have to keep them in Microsoft/vscode as well when that happens.

@Tyriar
Copy link
Member

Tyriar commented Jul 14, 2017

Opened microsoft/TypeScript#17200

@jrieken jrieken added this to the July 2017 milestone Jul 17, 2017
@jrieken jrieken modified the milestones: August 2017, July 2017 Jul 25, 2017
@jrieken
Copy link
Member Author

jrieken commented Jul 26, 2017

Closing this as most work is done except for xterm which is tracked in #31216

@jrieken jrieken closed this as completed Jul 26, 2017
@Tyriar Tyriar removed their assignment Aug 28, 2017
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
engineering VS Code - Build / issue tracking / etc. perf
Projects
None yet
Development

No branches or pull requests

2 participants