-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Split Node
type into more appropriate types
#33432
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
Labels
Needs Investigation
This issue needs a team member to investigate its status.
Comments
@rbuckton this looks like a promising angle of analysis - please follow up on the associated PR |
BTW, here is a more detailed list of all the Nodes ( Oh github, Y U NO fenced code blocks inside of
|
I think this was tried and didn’t lead to any more wins. In any case, I won’t be working on this anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently did some heap profiling and noticed that v8 makes all the
Node
objects the same size.Even though TS internally differentiates between Node / Identifier / Token, v8 still treats them the same because they come from the same constructor function.
Splitting those up can lead give up to ~8% reduction in memory usage, as shown in my PR here: #33431
I also noticed that the
Token
type is not really a good fit, since also literals like numbers, strings, boolean, etc are of typeToken
, but they do participate in type-checking and thus get additional properties later on, which is not ideal for performance (although my PR did not show any significant change).So my questions here are:
id
, but they still have now because of literals.So far, I only looked at typecker performance when run through
tsc
. So far, I have no idea howtsserver
works with regards to incremental parsing and checking. Is the type of a node immutable on incremental parsing / checking?The text was updated successfully, but these errors were encountered: