ts_library build performance

[matthewjh]

Hi,

I'm curious about ts_library build performance and what is normal/acceptable and what isn't. Having converted our company monorepo to ts_library targets (actually ts_library that uses the anguar Ivy wrapped tsc), I'm kind of surprised at how long a cold build takes. Yes, caching will mitigate a lot of it, but I want to make sure there is nothing else amiss here.

When I check out this repo @ stable and bazel build //src/app in examples/angular, with --profile, here are the results. To me it seems quite long but I don't know why, or whether my expectations are just off. Not clear to me how much of the time is in tsc or in ng compiler, and I don't know how to find out.

For ex, 9s to build //src/shared/material material? Where does that time go? Is there a way to get that information?

Can anyone else do the same (clean) build with profiling on and post their results for very rough comparison?

npx bazel build //src/app  --profile=myprofile

npx bazel analyze-profile myprofile

=== PHASE SUMMARY INFORMATION ===

Total launch phase time         0.164 s    0.56%
Total init phase time           0.463 s    1.60%
Total loading phase time        0.002 s    0.01%
Total analysis phase time       0.009 s    0.03%
Total preparation phase time    0.022 s    0.08%
Total execution phase time     28.363 s   97.71%
Total finish phase time         0.001 s    0.01%
------------------------------------------------
Total run time                 29.027 s  100.00%

Critical path (28.243 s):
       Time Percentage   Description
    9.075 s   32.13%   action 'Compiling TypeScript (devmode) //src/shared/material material'
   11.855 s   41.98%   action 'Compiling TypeScript (devmode) //src/app/hello-world hello-world'
    7.314 s   25.89%   action 'Compiling TypeScript (devmode) //src/app app'

Best, Matt

[alexeagle]

This is also a cold build that includes starting the typescript compiler. I recommend https://github.com/gregmagolan/ibazel-benchmark-runner - it's super-easy to hook up and gives us a more accurate baseline for fixes.

This is a great issue for us to dig into. A couple early thoughts:

• If you're on mac, I think sandbox creation is counted in execution phase and is known to be slow. I've been trying to turn off mac sandboxing by default - see recent PR
• The easiest data source is to run typescript with the --diagnostics flag, then TypeScript gives us a report of where it saw time spent. ts_library is running tsc_wrapped, a binary that wraps tsc. I've tried before to pass --diagnostics but I don't remember if it works
• we don't have a good recipe to produce nodejs profile data for any Bazel run. I think we'd want a --config=profile option in the common.bazelrc to enable any needed bazel flags, as well as some --define=NODE_PROFILE_TARGET=//some:target that would tell it to produce the profile file (might need to be declared as an output of the action as well)- something like this would be a great contribution

[mattem]

Some data here while profiling out builds, as we are seeing similar issues.

bazel profile output (mainly ts_library with Angular plugin) bazel-2020-08-25-v2-command.profile.gz

ts_library profiling output ev_tooling_haystack_site.json.zip

[DavidANeil]

I've tried before to pass --diagnostics but I don't remember if it works

It doesn't, that flag is only parsed if using the tsc command line, AFAIK there is no way to enable it while using the compiler API directly.

[DavidANeil]

I did some performance tracing and was seeing a large portion of time was consumed inside of tsc itself, I opened https://github.com/microsoft/TypeScript/issues/37701 in regards to that.

[evmar]

I updated https://github.com/microsoft/TypeScript/issues/37701 with my understanding of the cause.

[DavidANeil]

https://github.com/bazelbuild/rules_nodejs/issues/1497 was just closed, but it also is the same root cause.

I have been tinkering around in rules_typescript with some inspiration from @evmar's post and am seeing very promising results. Best case improvement was a 4x speedup.

My solution was pretty hacky, and doesn't work with sandboxing yet, but should be feasible.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 90 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 90 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions[bot]]

This issue was automatically closed because it went two weeks without a reply since it was labeled "Can Close?"