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

Revert 'require' word optimization #63

Open
ashaffer opened this issue Jan 22, 2016 · 1 comment
Open

Revert 'require' word optimization #63

ashaffer opened this issue Jan 22, 2016 · 1 comment

Comments

@ashaffer
Copy link
Member

@zertosh What do you think about reverting the regex optimization so that syntax-error can be removed upstream?

Giant libraries with no require calls should be noParse'd anyway, and the performance difference, while significant, is only really marginal. Whereas the performance difference gleaned by removing syntax-error upstream is asymptotic and enormous.

IMO the bundle time of incremental re-builds is more important than one off full rebuilds, since incrementals are executed constantly (and also could be cached by browserify-incremental if you wanted).

I'm requesting this per your comment in this thread:

browserify/browserify#1208 (comment)

If you did this and merged in your sm-fast branch, we could have really awesome rebuild times I think.

@zertosh
Copy link
Member

zertosh commented Jan 23, 2016

Incremental rebuilds already get the benefit of skipping syntax-error. You'd be surprised how many do not noParse giant libs. But, giant libs are usually derequired or minified, so they benefit from the regex optimization more than the cost of syntax-error.

I haven't worked on sm-fast recently. I'll try to take it up this weekend. It's more complicated than it seems. It requires substantive changes to browser-pack, which result in slightly different source map output (mostly related to empty lines in the prelude and the line used by the module wrapper). But the changes don't end there. insert-module-globals also does source map concating, so it should use the same lib as browser-pack.

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