-
Notifications
You must be signed in to change notification settings - Fork 253
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
Poor Performance, build times >30 seconds #112
Comments
I was thinking that it might be possible to use a language service the way ts-loader does. Looking over the code from ts-loader, I think it might be possible to re-use parts of its implementation: |
I'm seeing this performance issue in my react-styleguidist project as well. Parsing props takes up the largest portion of the build time by far, with total build time ~300 seconds. My environment is up-to-date Windows 10, using Node 10.15.3 LTS and the latest Git Bash. The work done by denieler on strothj/react-docgen-typescript-loader#40 seemed promising, so I tried porting it over for use in I've put the relevant code up as a Gist. Since it's mostly code from strothj/react-docgen-typescript-loader |
It’d be awesome to get that feature moved here so everyone can benefit. I’m unfortunately completely swamped at the moment but if the functionality is moved here we can make the adjustment at the loader side. |
I'm quite interested in this issue, as it has bogged down our Storybook experimentation quite a bit. |
I've replied on your issue, hopefully that improves things a bit. Right now the TypeScript instance is being reused in the loader. If we move that code from the loader to this parser here, the loader performance will stay the same but Styleguidest will also benefit. |
@strothj Things appear to have regressed. This is with both 3.1.1 and 3.2.0. |
any update on this issue? |
I've got a project that was taking almost 3 minutes to compile. This brought it down to ~10s. |
For anyone who is interested I wrote a plugin for webpack that does all the doc generation at once at the end of the build. https://github.com/hipstersmoothie/react-docgen-typescript-plugin This dramatically improved our start times over the loader. For styleguidist users the gist shared above is probably the best way to go |
There was no activity for a long time. Closing this issue as obsolete. In case it is still valid, please, open a new one. |
Closing this issue as obsolete. |
I am currently using this package with a project that has about 75 components. Each of these components can take over 500ms to parse. This causes our compile times (and live-reload times) to be close to 40 seconds between each change.
I have noticed that the parser creates a new Typescript program (ts.createProgram) a new Parser, which take about 400ms and 150ms each. This of course gets ran once for every component.
I have prototyped out a solution that caches the Typescript program and Parser based on the file path and can shave off almost 35 seconds from our build time. This of course is not a production solution, and there are probably plenty of cases where this wouldn't work.
I have also prototyped a version where there is one instance of the Typescript program and Parser and it gets replaced whenever there is a new filepath to compile. However I feel that this solution is less robust and probably has many more cases for regression.
I just wanted to open a conversation to the experts to see if there is an easy solution to this problem and if anybody else has run into similar issues. Thanks for all the great work with styleguidist. It makes the development of our React component library way easier and has forced our team to write documentation :D, which is a win-win.
The text was updated successfully, but these errors were encountered: