Investigate removing the concept of object allocators

Aberta
#52,958 0 comentários 0 reações 1 responsável Ver no GitHub

@rbuckton já está trabalhando nisso.

Desde 25/2/2023.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

Committed Domain: Performance Experimentation Needed Infrastructure Suggestion

Today we have the concept of an "object allocator". This is basically a set of functions, each which returns a constructor function for a commonly used data structure in the compiler.

/** @internal */
export interface ObjectAllocator {
    getNodeConstructor(): new (kind: SyntaxKind, pos: number, end: number) => Node;
    getTokenConstructor(): new <TKind extends SyntaxKind>(kind: TKind, pos: number, end: number) => Token<TKind>;
    getIdentifierConstructor(): new (kind: SyntaxKind.Identifier, pos: number, end: number) => Identifier;
    getPrivateIdentifierConstructor(): new (kind: SyntaxKind.PrivateIdentifier, pos: number, end: number) => PrivateIdentifier;
    getSourceFileConstructor(): new (kind: SyntaxKind.SourceFile, pos: number, end: number) => SourceFile;
    getSymbolConstructor(): new (flags: SymbolFlags, name: __String) => Symbol;
    getTypeConstructor(): new (checker: TypeChecker, flags: TypeFlags) => Type;
    getSignatureConstructor(): new (checker: TypeChecker, flags: SignatureFlags) => Signature;
    getSourceMapSourceConstructor(): new (fileName: string, text: string, skipTrivia?: (pos: number) => number) => SourceMapSource;
}

Why do this? Because for our batch compiler, TypeScript uses constructors with more bare-bones objects. For the most part, there are no members on the prototype, and we work purely with instance-set data.

On the other hand, the language service and TypeScript's API provides constructors that are attached to richer prototypes. For example, Nodes constructed by the language service have methods like getStart(), getEnd(), getSourceFile(), etc. These are partially for convenience and if my memory serves correctly, partially to power backwards-compatibility going back to TypeScript 1.0's tree API.

However, managing the two is slightly annoying, and creates layers of indirection. It would be nice to see if we can move away from this indirection and whether it can eliminate runtime overhead at all.

Linguagem predominante
Go
Estrelas
111k
Forks
14.4k
Merge médio
1d 19h
PRs com merge (30d)
117

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/TypeScript

Todas as issues de microsoft/TypeScript

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.