-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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
Experiment - monomorphic node/type/signature #58928
base: main
Are you sure you want to change the base?
Experiment - monomorphic node/type/signature #58928
Conversation
@typescript-bot perf test this |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
startupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
This is the most green thing I've seen this week. Nice!! |
Unfortunately I didn't see a noticeable perf improvement in the Airtable code base, but did see a 5-10% increase in peak memory usage. |
@MichaelMitchell-at i find this a bit surprising. While the % of difference varies, we've generally noticed improvements across the board. Is this a public repo? If it not, could you run the tsc on this branch through dexnode to get a report for the inline caches? Also how did you measure the times? What is the output with - - diagnostics? |
Actually there seems to be an error with my methodology so throw out the previous result I mentioned. I can't seem to apply the patch cleanly at the moment. I'll just have to wait for this to reach nightly. |
Ok, I looked into it a bit more. Our custom runner uses the compiler API and that code path hasn't been updated to support the new node structure yet.
I should be able to get past this if I can swap out this part with a lib that can parse JSON with comments and trailing commas. Edit: |
49b3d87
to
977cbc5
Compare
@typescript-bot perf test this |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
startupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Latest perf results seemed to have clawed back most of the parser perf loss. |
Half a gig of memory for vscode is a bit scary, though, given how close that is to the max memory limit... |
…node to reduce memory usage.
@jakebailey I did some extra work. I was too eager to make everything monomorphic, a bit of polymorphism is fine. There should be 3 shapes for nodes now: Token, Identifier and Node. There is a 4th one Token with With these changes, at least locally the increase in mem usage goes form 13% to about 5%, while keeping the same performance profile. |
@typescript-bot perf test this |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
startupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Much better, though emit is now much slower on certain benchmarks. Maybe a case or two aren't monomorphic for those benchmarks? |
For the extra parse time I have a pretty good idea. Will look into it a bit more. |
Starting jobs; this comment will be updated as builds start and complete.
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@typescript-bot perf test this faster [email protected] commits=aa249c094b9b96c86025e964469ed4c803190cca...977cbc5 |
Starting jobs; this comment will be updated as builds start and complete.
|
@jakebailey Here they are:
tscComparison Report - aa249c0..977cbc5
System info unknown
Hosts
Scenarios
Developer Information: |
I really am not sure what to do with this particular line:
The original usage already seems pathological as the same tests in node takes 2.3GB not 7.5GB, and this PR makes it much worse, but I don't really think this is truly an issue with the PR seems like an issue with bun IMO. Still 9% faster though 😅 |
Yeah 7 GB is quite high We should add some more environment variables to test things, but I wonder if passing |
The benchmark in question is equivalent to running |
I reverted back to the fully monomorphic version and tried to reduce the memory usage on that. The critical insight came when I realized that most of the extra memory allocated was actually not in the new objects themselves, but rather in a property array that v8 uses to store dynamic properties for objects. Creating the data object with all the properties the node might have right in the node factory means that v8 will no longer create the property array thus reducing memory consumption. The same can be applied to Type to further reduce memory, but that seems a bit more difficult since type creation is not as centralized, but I will in investigate further if the @jakebailey When you get a chance can you please run the tests again? |
@typescript-bot perf test this |
Starting jobs; this comment will be updated as builds start and complete.
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
startupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
For For
Excluding the outliers we get: Increase of 🔻 3-15% in memory for a perf win of 🟩 3-16%. A much more mixed result |
I moved some stuff around between node and node data. This seems to reduce some more of the extra memory that was being used. I also experimented with reducing the size of Types, but don't think there are any easy wins there. @jakebailey When you get a chance, can you run the tests again please? |
@typescript-bot perf test this |
Starting jobs; this comment will be updated as builds start and complete.
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
startupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Good stuff. On Node the mean averages for
...which is an exchange rate of 4.2 |
It's worth keeping in mind that if TSServer requires more than 4096 MB of memory then VSCode can no longer use its prebuilt version of Node with pointer compression, which has a significant effect on interactivity performance. So it might be worth re-measuring that exchange rate on projects that are close to reaching that threshold. I plan to do this on the Airtable monorepo (which at this point has already blown past the 4GB memory limit, but we hope to eventually bring it down), once the PR is stable. |
Experiment to make several objects monomorphic by keeping the common properties in a single object shape and moving all other properties to a separate object and using accessors to preserve compatibility with existing code.
Local improvements seem promising, building TSC/compiler: ~-20% in time with ~+10% in memory.
Code is rough around the edges, just testing out as a proof of concept.
Note: This is the result of me and @acutmore bouncing ideas about improving access to
Node.kind