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

See if we can utilize WebAssembly source-map stuff #45

Open
stefanpenner opened this issue Jan 18, 2018 · 9 comments
Open

See if we can utilize WebAssembly source-map stuff #45

stefanpenner opened this issue Jan 18, 2018 · 9 comments

Comments

@stefanpenner
Copy link
Collaborator

mozilla/source-map#306

cross post: broccolijs/broccoli-concat#120

@Turbo87
Copy link
Collaborator

Turbo87 commented Mar 23, 2018

the new stuff is Node 8+, which we can't support until some time next year unfortunately... (see https://github.com/mozilla/source-map/blob/master/package.json#L58)

@vlascik
Copy link
Contributor

vlascik commented Mar 23, 2018

You could always bump a major version and have users opt-in to it if they don't need Node 6 (which is probably almost everyone). Source-map generation is ~30% of rebuild time, it makes a lot of sense to try to fix it sooner than next year.

@Turbo87
Copy link
Collaborator

Turbo87 commented Mar 23, 2018

we can do that for this lib, yes. but it is used inside Ember CLI and we can't just bump major there and drop Node 6 support earlier than planned.

@vlascik
Copy link
Contributor

vlascik commented Mar 23, 2018

I know you can't do it by default, but developers are generally advanced enough users to be able to force a new version for ember-cli via resolutions, if it meant faster rebuilds.

@ef4
Copy link
Owner

ef4 commented Mar 24, 2018

The cost of having two implementations in node is basically not important (especially when you consider that most people end up with possibly dozens of copies of common utility libraries in a big node project). So it's plausible to ship a version of this lib that uses webassembly where available and uses a pure JS implementation otherwise.

@ef4
Copy link
Owner

ef4 commented Mar 24, 2018

(I mean in terms of app performance, obviously there is maintainer overhead. But if we were only keeping the existing JS implementation around for backward compat and kept all new work in the webassembly one, I think it would be manageable.)

@puzrin
Copy link

puzrin commented Sep 2, 2020

Sorry for stupid question, but why don't you use indexed format for sourcemap concat? It has zero cost and 100% compatibility.

If you care about performance, it would be optimal to load such "concatenated" sourcemap once via sourcemap v0.8.0. It already has all required optimizaions.

@ef4
Copy link
Owner

ef4 commented Sep 2, 2020

Way back when this was written, the indexed format definitely did not have broad compatibility. If that has changed, great.

@puzrin
Copy link

puzrin commented Sep 4, 2020

Way back when this was written, the indexed format definitely did not have broad compatibility. If that has changed, great.

FYI, some technical details:

  1. Chrome supports indexed format, if not multi-level nested. In dev mode (without minifier), build of such map is significantly faster.
  2. In our code, [terser (sm 0.6.1 inside) + 1-level indexed sourcemap] vs [terser + fast_concatenated sourcemap] take ~ the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants