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

tsify is slow #227

Closed
JohnLouderback opened this issue Aug 25, 2017 · 8 comments
Closed

tsify is slow #227

JohnLouderback opened this issue Aug 25, 2017 · 8 comments

Comments

@JohnLouderback
Copy link

JohnLouderback commented Aug 25, 2017

I'm wondering if I haven't made a glaring mistake, but tsify is taking around a minute and half to build our codebase's JS whereas with just Flow and Babel it would take around 7 seconds. I've also noticed that if I get any Typescript errors, I'll usually get around 6 repeated of the same error for the same line and column. Are there any caveats I should be aware of, or is tsify just slow?

capturfiles-aug-25-2017_09 28 51

@cartant
Copy link
Contributor

cartant commented Aug 26, 2017

In certain situations, tsify can be rather slow. This has a lot to do with the limited communication that's possible between Browserify and its plugins and transforms.

tsify works by compiling the TypeScript program, holding the results of the compilation in memory, and returning the compiled content to Browserify via a transform. If transform sees a file that was not part of the compilation, the cache miss will effect a re-compilation. And that can be slow.

tsify contains diagnostic logging that can be enabled using NODE_DEBUG (see https://github.com/TypeStrong/tsify/blob/master/CONTRIBUTING.md#debugging) and that will clearly show which files are causing cache misses, if they are occurring.

However, I'm not sure that's your problem. It's not clear to me what build system you are using, but looping through the results of that glob doesn't look right. Unless you are creating multiple bundles, I don't see why you need to repeatedly call browserify, etc. for each .ts and .js file.

Usually, you specify only the entry point file and Browserify will slurp up the dependent files using require - or import, for .ts files.

@HerringtonDarkholme
Copy link

Hi @cartant . I would suggest add a transpileOnly flag to tsify. Like https://github.com/TypeStrong/ts-loader#transpileonly-boolean-defaultfalse

@JohnLouderback
Copy link
Author

@cartant I'm using Gulp. Our build process is configured to bundle multiple top level JS/TS files. Setting NODE_DEBUG=tsify appears to make no discernable difference. I don't see any further output.

@cartant
Copy link
Contributor

cartant commented Sep 5, 2017

Without knowing more about your setup, there's not much that can be said. Why are you globbing and bundling every file that matches the glob? That's looks very strange.

@cartant
Copy link
Contributor

cartant commented Sep 5, 2017

For the record, it's possible to use multiple top-level files, but you would normally add them and bundle once. You are bundling with each added, top-level file.

@cartant
Copy link
Contributor

cartant commented Sep 5, 2017

@HerringtonDarkholme Thanks. I'll bear that in mind. However, I don't have a great deal of time to allocate to this project, at the moment; I'll add it to the backlog.

@JohnLouderback
Copy link
Author

@cartant The glob is because there top-level files are independent bundles. If there's any specific information about our build process you'd like to know, I'd be happy to share with you. Unfortunately, if I can't resolve the 7 second to 1.5 minute build time increase, TypeScript won't be an option for us. Any help would be extremely appreciated. Are minute and a half build times common for tsify?

@cartant
Copy link
Contributor

cartant commented Sep 14, 2017

The baseline to use to determine whether or not tsify is slow is tsc - the TypeScript command line compiler. For a one-off build, tsify is not going to be faster than that. If it is significantly slower, it's possible that there could an issue to address.

@cartant cartant closed this as completed Sep 14, 2017
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

3 participants