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

core/standard-whitespace-parsers block DCE in CLJS #175

Open
pkpkpk opened this issue Dec 14, 2017 · 1 comment
Open

core/standard-whitespace-parsers block DCE in CLJS #175

pkpkpk opened this issue Dec 14, 2017 · 1 comment

Comments

@pkpkpk
Copy link
Contributor

pkpkpk commented Dec 14, 2017

Due to parser construction in a top level definition and their use in parser opts, the standard-whitespace-parsers and their associated parser setup code cannot be pruned by google closure, even when they are not used.

I have written my own parser object that skips the formatting options etc and calls the gll namespace directly. If I comment out the whitespace parsers from core, this shaves ~80kB off a minified build, though YMMV.

This issue will be useful to CLJS ppl but its unclear if this can be fixed without making big api changes, so feel free to close

@aengelberg
Copy link
Collaborator

aengelberg commented Feb 7, 2018

I experimented by compiling the test runner in the instaparse project under the following conditions:

  • don't even compile instaparse source files = 257KB
  • (:require [instaparse.core]) = 392KB
  • (:require [instaparse.core]) + comment out auto-whitespace parsers = 392KB
  • (:require [instaparse.gll]) = 392KB
  • (:require [instaparse.gll]) + comment out auto-whitespace parsers = 286KB

I could easily fix the auto-whitespace problem by adding a delay to the globally defined parsers (I tried that and got similar results to commenting them out entirely). However, as you have discovered, shipping that change would still require users to totally bypass the core API (like you did) in order to see any meaningful dead code removal. And I'm not sure the best way to optimize the day-to-day use case without completely refactoring the entire library.

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

2 participants