Skip to content

Commit

Permalink
Add documentation about performance profiling (#1230)
Browse files Browse the repository at this point in the history
Co-authored-by: John Reilly <johnny_reilly@hotmail.com>
  • Loading branch information
berickson1 and johnnyreilly authored Dec 30, 2020
1 parent 3cc78b8 commit 14fa3f8
Showing 1 changed file with 28 additions and 1 deletion.
29 changes: 28 additions & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,4 +60,31 @@ Just like the steps above, except substituting a local copy of ts-loader for the
3. In your own Webpack project directory, run `npm link ts-loader`. There’s now a chain of symlinks from `node_modules/ts-loader` to your cloned copy built from source.
4. Repeat the steps above in “Debugging ts-loader installed from npm...” except now, you can take advantage of source maps, so you can set breakpoints in `ts-loader/src` instead of `ts-loader/dist`.
5. If you want to try making changes to `ts-loader`, make changes and then repeat steps 1 and 4—no need to re-run the `npm link` steps.
6. Run `npm unlink ts-loader` in your own project directory to remove the symlink when you’re done.
6. Run `npm unlink ts-loader` in your own project directory to remove the symlink when you’re done.

### Profiling Performance

To investigate slowdowns in build times, it's often helpful to profile webpack & ts-loader.

1. Start webpack with a debugger attached (see debugging steps above)
2. Identify the reproducible user scenario that is experiencing slowdowns
3. In Chrome, open `chrome://inspect` and inspect the running webpack instance
Note: Utilizing Chromium instead of Chrome sometimes yeilds better results. If any of the following steps fail or cause a crash, try switching from Chrome to Chromium.
4. Switch to the Profiling Tab
5. Start Recording
6. Kick off the scenario that's known to be slow
7. Stop Recording once the scenario is complete

At this point you should see a list of function calls. There are three distinct views that are useful & you can swap between them to get slightly different views of the problem.

**Chart View**

The chart view will provide a flame chart of all profiled function calls over time. This can be useful to visualize expensive functions and blocks of high CPU, but can be difficult to read when there are deep call stacks (or flames).

**Heavy View**

Heavy view shows the time that functions took to execute themselves (self time) & the functions they call (total time). When expanding individual calls, you will be able to see the functions that called this function & effectively walk up the recorded stack traces.

**Tree View**

Tree view shows the same information as heavy view, but visualizes calls in a top-town manner. This can be useful to track down a single call pattern that is expensive but is less useful when there are deep stack traces.

0 comments on commit 14fa3f8

Please sign in to comment.