-
-
Notifications
You must be signed in to change notification settings - Fork 673
Use lazy initializations for decorators and type parameters in parser #554
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
Conversation
@@ -939,7 +939,8 @@ export class Parser extends DiagnosticEmitter { | |||
|
|||
// at '<': TypeParameter (',' TypeParameter)* '>' | |||
|
|||
var typeParameters = new Array<TypeParameterNode>(); | |||
// var typeParameters = new Array<TypeParameterNode>(); | |||
var typeParameters: TypeParameterNode[] | null = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I'm wondering: If we are already at <
, the usual case here is that we'll end up with an array and not null
since <>
is invalid. If we had the Array.create<TypeParameterNode>(1)
helper I mentioned in the runtime PR (the one that would guarantee a backing buffer for at least one element but with length=0), that might make the most sense here as it avoids the (most of the time) redundant null check below. Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could be even better. Reserve not 1 element but for example 8 when array is created. And this elements btw could store outside of buffer exactly inside Array class. Similar approach have SmallVector in binaryen and LLVM's SmallVector
No description provided.