It sounds like process.exit might truncate in-flight I/O, so use process.exitCode in non-error scenarios.

(I'm tentatively assuming that a tiny message sent to stdout/stderr immediately before exit will make it to the console.)

Fixes #33

Something here is breaking, because it's cutting off our output.

    return new Promise<ProjectResult>(resolve => {
        const child = cp.fork(path.join(__dirname, "analyze-trace-file"), args, { stdio: "pipe" });

        let stdout = "";
        let stderr = "";

        child.stdout!.on("data", chunk => stdout += chunk);
        child.stderr!.on("data", chunk => stderr += chunk);

        child.on("exit", (code, signal) => {
            resolve({
                project,
                stdout: stdout.trim(),
                stderr: stderr.trim(),
                exitCode: code ?? undefined,
                signal: signal ?? undefined,
            });
        });
    });

If we run analyze-trace-file on the command line with the same arguments it works fine.

I tried setting maxBuffer but that's not an option for fork, and even if I changed it to exec it still fails with the same problem.

This is what it looks like when the output gets cut off. Maybe exit is being fired before all of on('data') had a chance to fire?

jsonparse is used in analyze-trace-file.ts but is not declared as a dependency.

Yarn >=2 with PnP throws an error when running yarn dlx @typescript/analyse-trace trace-dir because it is stricter with dependencies.

Error: @typescript/analyze-trace tried to access jsonparse, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

Required package: jsonparse

There are a bunch of constants that govern ultimately how many results are shown:

https://github.com/microsoft/typescript-analyze-trace/blob/fbca82e26714dc44ac76d667a1b67072c1c30de4/src/analyze-trace-file.ts#L31-L33

IMHO perhaps those constants should be customizable from the CLI, or even better there should just be a "limit" flag to limit the number of files outputted, which by default could be 10 or even the current essentially "auto" limit.

Was https://github.com/amcasey/ts-analyze-trace/issues/7 from @fabiospampinato

Fixes #21

TODO: If I were doing this from scratch, I would probably implement JSON as the default output and then have a wrapper that pretty-prints the output as text. As things stand, there are two distinct implementations that share a lot of helper functions. The biggest difference between the two is that JSON nodes use explicit children properties (i.e. follow a schema), whereas text output nodes follow treeify's structure (i.e. children are dynamically generated properties on parent node).

NB: While JSON is obviously intended for programmatic consumption, please don't take a dependency on the output format yet. Until a non-trivial consumer flushes out the bugs, it can't really be considered stable.

Hi!

First, thanks for this tool ! I've tried to use it on a very big project to find hot spots. Here is an example of output:

Hot Spots
├─ Check file d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\abtestingtabs\abtestdashboard.ts (2316ms)
│  └─ Check variable declaration from (line 164, char 11) to (line 164, char 51) (1909ms)
│     └─ Check expression from (line 164, char 21) to (line 164, char 51) (1909ms)
│        └─ Determine variance of type 13937 (1908ms)
│           ├─ Compare types 20107 and 20106 (1074ms)
│           │  └─ Compare types 20191 and 20190 (1064ms)
│           │     └─ Compare types 20197 and 20198 (1064ms)
│           │        └─ Determine variance of type 20192 (1064ms)
│           │           └─ Compare types 20200 and 20199 (1048ms)
│           │              └─ Compare types 20203 and 20202 (1048ms)
│           │                 └─ Compare types 20214 and 20213 (1047ms)
│           │                    └─ Determine variance of type 20208 (1046ms)
│           │                       └─ Compare types 24092 and 24091 (748ms)
│           │                          └─ Compare types 24290 and 24289 (708ms)
│           │                             └─ Check expression from (line 177, char 2) to (line 177, char 2) (708ms)
│           │                                └─ Determine variance of type 14841 (706ms)
│           │                                   └─ {"id":14841,"kind":"GenericType","name":"ButtonProperties","typeArguments":[14842,14843,14844,14845,14846,14847,14848,14849,14850,14851],"location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":1}}
│           │                                      ├─ {"id":14842,"kind":"TypeParameter","name":"K","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":35}}
│           │                                      ├─ {"id":14843,"kind":"TypeParameter","name":"S","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":48}}
│           │                                      ├─ {"id":14844,"kind":"TypeParameter","name":"KText","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":61}}
│           │                                      ├─ {"id":14845,"kind":"TypeParameter","name":"SText","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":78}}
│           │                                      ├─ {"id":14846,"kind":"TypeParameter","name":"KIcon","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":95}}
│           │                                      ├─ {"id":14847,"kind":"TypeParameter","name":"SIcon","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":112}}
│           │                                      ├─ {"id":14848,"kind":"TypeParameter","name":"KImage","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":129}}
│           │                                      ├─ {"id":14849,"kind":"TypeParameter","name":"SImage","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":147}}
│           │                                      ├─ {"id":14850,"kind":"TypeParameter","name":"KAnimated","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":165}}
│           │                                      └─ {"id":14851,"kind":"TypeParameter","name":"SAnimated","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\button.ts","line":20,"char":186}}
│           └─ Compare types 35048 and 35047 (834ms)
│              └─ Compare types 35074 and 35073 (650ms)
│                 └─ Compare types 35077 and 35076 (650ms)
│                    └─ Compare types 35080 and 35079 (649ms)
│                       └─ Determine variance of type 14166 (648ms)
│                          └─ Compare types 35101 and 35100 (556ms)
│                             └─ Compare types 35132 and 35131 (546ms)
│                                └─ Compare types 35136 and 35134 (546ms)
│                                   └─ Compare types 35135 and 35133 (546ms)
│                                      └─ Compare types 35107 and 35102 (545ms)
│                                         └─ Determine variance of type 35081 (545ms)
│                                            └─ Compare types 36320 and 36319 (421ms)
│                                               └─ Compare types 36360 and 36356 (408ms)
│                                                  └─ Compare types 36357 and 36353 (295ms)
│                                                     └─ Determine variance of type 35199 (295ms)
│                                                        └─ Compare types 36397 and 36396 (225ms)
│                                                           └─ Compare types 36422 and 36421 (221ms)
│                                                              └─ Compare types 36435 and 36433 (220ms)
│                                                                 └─ Compare types 36434 and 36432 (220ms)
│                                                                    └─ Compare types 36407 and 36400 (218ms)
│                                                                       └─ Determine variance of type 36375 (218ms)
│                                                                          └─ {"id":36375,"kind":"GenericType","name":"HeaderProperties","typeArguments":[36376,36377,36378,36379,36380,36381,36382,36383,36384,36385],"location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":1}}
│                                                                             ├─ {"id":36376,"kind":"TypeParameter","name":"K","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":35}}
│                                                                             ├─ {"id":36377,"kind":"TypeParameter","name":"S","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":43}}
│                                                                             ├─ {"id":36378,"kind":"TypeParameter","name":"KSubHeader","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":51}}
│                                                                             ├─ {"id":36379,"kind":"TypeParameter","name":"SSubHeader","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":68}}
│                                                                             ├─ {"id":36380,"kind":"TypeParameter","name":"KIcon","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":85}}
│                                                                             ├─ {"id":36381,"kind":"TypeParameter","name":"SIcon","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":97}}
│                                                                             ├─ {"id":36382,"kind":"TypeParameter","name":"KImage","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":109}}
│                                                                             ├─ {"id":36383,"kind":"TypeParameter","name":"SImage","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":122}}
│                                                                             ├─ {"id":36384,"kind":"TypeParameter","name":"KText","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":135}}
│                                                                             └─ {"id":36385,"kind":"TypeParameter","name":"SText","location":{"path":"d:\workspaces\xlefebvre\customer\royal\middleoffice\sparkowstudio\src\js\components\elements\header.ts","line":20,"char":147}}

To find the types in question, i'm using the command simplify-trace-types and search for type ids in generated file. But it's can of tedious to go back and forth between the two files. Would it be possible to have an option for analyze-trace to inline type names ? and another maybe for their location ? (like it's already done for the leafs of the output).

Maybe something like this:

When running as instructed we get the following error:

This PR fixes the instruction of the README by changing to the correct package name @typescript/analyze-trace.

With a bit of time, someone using this tool can probably figure out what commands to run - but if we could make it clearer from a quick glance to

just run this!

with codeblocks and and headings and the like, we can make the process feel less overwhelming.

This tool is great, I solved a few problems thanks to it.

So I thought that I would add it as a step of our CI to prevent regressions or adding new performance issues. But our CI runs on much slower machines than mine so it catches a lot more things.

Isn't there a metric more constant that this tool could be based on to figure out how much typescript has to work and where things could be improved?

We've seen some projects slowed down by pulling in a huge number of files from a library when they really only wanted a small portion of the functionality. Ideally, the compiler itself would recognize this but, until then, flagging them could help people make spot fixes. Unfortunately, this seems to have a lot of false positive, esp in monorepos where node_modules might actually be user code.

Part of #2.

After looking at lots of traces it appears that JS emit is nearly always proportional (with a small constant) to file size (even with down-levelling), so flagging JS files that took a long time to emit rarely does anything beyond identifying large input files.

Declaration emit, on the other hand, is much less directly related to input size. So far, the most important factor we've found for disproportionately slow declaration emit is the presence of a lot of import expressions in the output. This PR attempts to flag such instances by searching slow-to-emit declaration files (if present) for import expressions.

Fixes #3 (until we find some other cause of disproportionate slowdown).

Showing the filename and line numbers is helpful, but it means a lot of manually digging when looking for common patterns.

I made another POC. The tree component may need to be fixed or replaced to support new lines.

As a developer using TypeScript, and not somebody developing TypeScript, it might even be more helpful to show less of the internal information, and instead display the results similar to how tsc shows errors.

BEFORE

 {"id":4961,"kind":"GenericTypeAlias","name":"Pick","aliasTypeArguments":[4909,4960],"location":{"path":"/users/dylang/repo/node_modules/typescript/lib/lib.es5.d.ts","line":1578,"char":1}}

AFTER

repo/node_modules/typescript/lib/lib.es5.d.ts:1578:1

1578 type Pick<T, K extends keyof T> = {
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It would be helpful if there was something like --watch mode, or documentation for how to do this.

Example workflow:

1. We run analyze-trace ts-trace
2. Oh look, a hot spot!

Analyzed /Users/dylang/project/packages/example/tsconfig.json (trace.65458-188.json)
Hot Spots
└─ Check file /Users/dylang/project/packages/example/slow-type-in-here.js (1739ms)
   └─ Check variable declaration from (line 57, char 7) to (line 62, char 2) (1441ms)
      └─ Check expression from (line 57, char 30) to (line 62, char 2) (1441ms)
         └─ Check expression from (line 57, char 30) to (line 57, char 52) (1438ms)
            └─ Compare types 13361 and 4729 (1249ms)

3. We make a change to try to fix it, and hit save....

This is where this feature request starts.

4. analyze-trace automatically runs again. Fewer files may need to be recompiled so analyze-trace is only showing results from those re-compiles. Feature Request
5. The output from analyze-trace tells us how much faster or slower each change is compared to the previous run. Bonus Feature Request

If I try running the trace analyzer with npx analyze-trace --color false > foo.txt, then foo.txt gets something like the following output.

Hot Spots
Γö£ΓöÇ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\typescript\lib\lib.dom.d.ts (816ms)
Γö£ΓöÇ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\@types\babel__traverse\index.d.ts (511ms)
ΓööΓöÇ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\@types\react\index.d.ts (507ms)

instead of the expected box drawing characters

Hot Spots
├─ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\typescript\lib\lib.dom.d.ts (816ms)
├─ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\@types\babel__traverse\index.d.ts (511ms)
└─ Check file c:\users\Daniel\scratch\ant-design-icons\packages\icons-react\node_modules\@types\react\index.d.ts (507ms)

This is apparently because Node.js outputs to UTF8, and PowerShell's redirection functionality (at least the version I'm using, 5.1) thinks it's receiving UTF16. The fix is to set

[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

Matrix:

• file vs dir
• types (un)available
• source (un)available
• json vs text

It needs to be possible to diff against the old baseline and accept the new baseline.

The biggest obstacle is likely to be source file lookup - real traces use absolute paths, but those won't be portable (e.g. to CI machines). Post-processing the trace files (i.e. test cases) to use forward-slash-delimited relative paths might suffice.

e.g. in x / y, / y will be classified as a regex (to EOL).

To handle this properly, we'd need a parser - you need to know whether the slash is at the start of an expression. Offsets in the incorrectly classified region will (probably) map to the correct line but an incorrect character position, since trivia skipping rules are different within regexes.