TransparentCompiler ignores keepAllBackgroundSymbolUses and enableBackgroundItemKeyStoreAndSemanticClassification, and caches every file's name resolution sink

Abierto
  • ¿Algo no está bien?
#20,755 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
fsharp
Área
compilers

Línea de trabajo

Start in src/Compiler/Service/TransparentCompiler.fs: the constructor parameters near L418-L419, TcResultsSinkImpl creation in ComputeTcIntermediate near L1423, the TcIntermediate cache type near L79-L92, and the collectSinks path in ComputeParseAndCheckAllFilesInProject near L1758. Done means the sink is only kept where keepAllBackgroundResolutions or keepAllBackgroundSymbolUses requires it, the XML doc is updated, and the existing transparent compiler tests still pass. This touches caching semantics across the compiler service, so confirm the approach with maintainers first.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Area-Compiler-Service Feature Improvement Theme-Performance

FSharpChecker.Create takes three options that decide how much of a background check the background compiler keeps. The transparent compiler stores two of them and never reads them, and reads the third for one field only:

  • keepAllBackgroundSymbolUses and enableBackgroundItemKeyStoreAndSemanticClassification are constructor parameters (L418-L419) and have no other use in TransparentCompiler.fs.
  • keepAllBackgroundResolutions only picks tcEnvAtEndOfFile (L1489).

ComputeTcIntermediate always creates a TcResultsSinkImpl (L1423) and keeps it in the TcIntermediate it caches (L79-L92). So every file that was type checked, also the files that were only checked because a later file depends on them, keeps all its name resolutions for as long as its TcIntermediate is cached. ComputeParseAndCheckAllFilesInProject also collects the sinks of all files of the project (collectSinks = true, L1758), and that is the path that produces the assembly data of an in-memory project reference.

With the background compiler, keepAllBackgroundResolutions = false and keepAllBackgroundSymbolUses = false drop the resolutions and symbol uses of the files it checked in the background.

Measured

FsAutoComplete with FCS 43.12.201, transparent compiler, default cache sizes, on the Fantomas solution. Session: open two files of Fantomas.Core, hover and navigate, then one Find References on SyntaxOak.Expr (672 references in 9 files). Dominator tree of a heap dump taken at the end:

Retained
Live heap 689 MB
CompilerCaches 386 MB
TcIntermediate cache, 108 entries 73 MB
The 108 TcResultsSinkImpl in those entries 34 MB

The same session with the options turned off in FsAutoComplete, one run each:

Options RSS after Find References
All three true (FsAutoComplete's default) 1,112 MB
keepAllBackgroundResolutions = false 1,117 MB
keepAllBackgroundSymbolUses = false, enableBackgroundItemKeyStoreAndSemanticClassification = false 1,134 MB

Run-to-run noise is about ±25 MB, so none of them changes anything. The links above point to main; 43.12.201 has the same code in these places.

Proposal

  • Honour keepAllBackgroundSymbolUses = false in ComputeParseAndCheckAllFilesInProject: do not collect the sinks. The background compiler does not keep the symbol uses either.
  • Honour keepAllBackgroundResolutions = false: keep the sink only for the file that was asked for. ComputeTcLastFile only uses the sink of the last file, so the TcIntermediate of the files before it does not need one. The cost is that opening one of those files later type checks it again, as with the background compiler.
  • enableBackgroundItemKeyStoreAndSemanticClassification: the transparent compiler builds both on demand from the sink, so the option means nothing there. Say so in its XML doc.

Expected gain: up to the 34 MB above for this session, more where in-memory project references are type checked for their assembly data. I have not measured that case.

Related: #8021 (the same data structure in the background compiler).

Lenguaje dominante
F#
Estrellas
4.3k
Forks
884
Merge medio
2 d 11 h
PR fusionados (30 d)
73

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/fsharp

Todos los issues de dotnet/fsharp

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.