| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping Sheetal Nandi (@sheetalkamat), Andrew Casey (@amcasey), Matt Bierner (@mjbvz), Mine Starks (@minestarks) for you. Feel free to loop in other consumers/maintainers if necessary |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) run dt |
Sorry, something went wrong.
|
Heya Nathan Shively-Sanders (@sandersn), I've started to run the perf test suite on this PR at 053b7dc. You can monitor the build here. Update: The results are in! |
Sorry, something went wrong.
|
Heya Nathan Shively-Sanders (@sandersn), I've started to run the parallelized Definitely Typed test suite on this PR at 053b7dc. You can monitor the build here. |
Sorry, something went wrong.
|
Nathan Shively-Sanders (@sandersn) Comparison Report - master..43312
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, something went wrong.
|
Here are the results for node 14 (the node 12 results are basically identical and I didn't look at node 10):
Memory usage is stable across runs, so these results are highly statistically significant. |
Sorry, something went wrong.
|
After looking closer at the results and doing some local testing, it looks like 1000 jsdoc = 1 MB of memory increase. I think that's fine. The number is alarming for activex-libreoffice because it has so much jsdoc and because checking is so easy. I recommend taking this change. |
Sorry, something went wrong.
|
Nathan Shively-Sanders (@sandersn) It sounds like you're saying that each jsdoc comment uses 1KB more memory than its string representation - is that right? That seems kind of high, doesn't it? How many objects is each comment turning into? |
Sorry, something went wrong.
|
The common case of a jsdoc comment with no links should create an additional NodeArray (an array instance-patched with 2 properties and optionally (rarely) 2 more) that contains a single JSDocText (a Node instance, which has 9 properties and optionally 12 more), which contains the string that was originally there. I did a quick experiment, which turned into a lot of measurement, to find the likelihood of bugs here. I compared master with this branch, as well as a branch that doesn't change the parser except to add a singleton NodeArray containing a JSDocText. It's at jsdoc-simple-parse-EXPERIMENT -- it's an obvious subset of this PR. It does not parse @link tags. Edit: After discussing ideas with Andrew Casey (@amcasey), I made the AST comment type: string | NodeArray<JSDocText | JSDocLink>. The common case still creates a string, and then walking the tree conditionally skips comments when it's just a string. I measured performance with this commit too. Memory usage is an average of 7 runs. activex-libreoffice16,000 jsdocs and 6,000 @link: master: 226k nodes, 114.4 MB (with a surprising amount of variance, much more than the +-500k I'm used to seeing) angular 23,000 jsdocs and 500 @link: master: 934k nodes, 445 MB compiler-unions1,000 jsdocs, 1 @link: There is quite a bit of variance in memory usage for compiler-unions. Maybe I'm seeing the effect of the new union cache? |
Sorry, something went wrong.
|
I might be blanking, but why do we do any of this work in tsc scenarios? Isn't @link purely for editor support? |
Sorry, something went wrong.
|
The way it's implemented now gives jsdoc texts a full AST parse. That form makes it much easier to produce displayparts for the editor. |
Sorry, something went wrong.
|
Right, but couldn't we skip that extra parsing in tsc scenarios? |
Sorry, something went wrong.
| const comments: string[] = []; | ||
| let linkEnd: number; | ||
| let commentsPos: number | undefined; | ||
| let comments: string[] = []; |
There was a problem hiding this comment.
Not new, but why is comments accumulated as an array of parts and joined later, rather than simply accumulated as a string?
Sorry, something went wrong.
There was a problem hiding this comment.
Habit from immutable-string languages without optimisations for +=. I'm not sure if JS is still one of these languages or not.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm pretty sure I remember reading that += is the fastest way to accumulate a string in JS, but I don't have a source.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm going to try this in a separate PR.
Sorry, something went wrong.
| readonly parent: HasJSDoc; | ||
| readonly tags?: NodeArray<JSDocTag>; | ||
| readonly comment?: string; | ||
| readonly comment?: NodeArray<JSDocText | JSDocLink>; |
There was a problem hiding this comment.
If we decided we were sufficiently bothered by the increased memory usage, could this be string | NodeArray? Alternatively, could we have JSDoc and JSDocWithLinks?
Sorry, something went wrong.
There was a problem hiding this comment.
We talked offline about some ways we might be able to reduce memory usage in common cases and I think it would be good to experiment with them. Otherwise, LGTM
Sorry, something went wrong.
|
The common case experiment worked out pretty well, except for activex-libreoffice, which has really weird characteristics already. I'm going to fix a bug in services that I introduced, push the commit, and run perf tests on it to make sure that it doesn't slow things down a lot. |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) perf test this |
Sorry, something went wrong.
|
Heya Nathan Shively-Sanders (@sandersn), I've started to run the parallelized Definitely Typed test suite on this PR at 4db5d97. You can monitor the build here. |
Sorry, something went wrong.
|
Heya Nathan Shively-Sanders (@sandersn), I've started to run the perf test suite on this PR at 4db5d97. You can monitor the build here. Update: The results are in! |
Sorry, something went wrong.
|
Nathan Shively-Sanders (@sandersn) Comparison Report - master..43312
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, something went wrong.
|
Perf looks good; only angular's memory usage goes up. Edit: DT is fine too, but I only ran that as insurance. |
Sorry, something went wrong.
update typescript to v4.3.5 add type annotations to methods that have an implicit any type in TS 4.3 - for more information, see microsoft/TypeScript#26623 map TS 4.3+ `JSDocTagInfo` to `CompilerJsDocTagInfo` - for more information, see microsoft/TypeScript#43312 add type guard for `TestingSystem`. in TS 4.3, `Object.defineProperties` is now generic, and returns the same type `T` as it's first argument. adding a typeguard allows consumers of this method to ensure they're receiving a `TestingSystem` object enable `noImplicitOverride` compiler flag
| Back | FazBrowse Home | New Git URL |
Same as #41877, but with an additional commit to fix parsing unterminated @link tags that go to the end of a comment.
Note that local runs of activex-libreoffice show memory usage 100 MB -> 118 MB and 226k -> 290k nodes, an 18% increase in memory and 28% increase in node count. That's quite a bit, although activex-libreoffice uses jsdoc and @link heavily.
I'm going to make sure that DT succeeds with this build and also look at memory use from the perf tests.