Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Rewatch: in-process bsc prototype

Offen
  • Stimmt etwas nicht?
#8,659 2 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
ocaml
Bereich
build-system, compilers, performance

Rechercherichtung

Beginne mit der OCaml-Rewatch-Neuimplementierung aus #8653 und verfolge, wie die ausführbare Datei bsc für die Schritte zum Parsen und Kompilieren aufgerufen wird, einschließlich der Builds von stdlib und Tests. Dokumentiere die beteiligten Artefakte und den gemeinsamen Zustand und definiere anschließend einen sequenziellen Prototyp-Benchmark sowie eine konkrete Empfehlung dafür, worauf eine spätere Implementierung abzielen sollte.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Based on the OCaml rewatch reimplementation from #8653, we can prototype integrating the compiler directly into the rewatch executable to avoid having to spawn a bsc binary for each compilation step.

@cristianoc fed the prompt below into Fable, and I fed the same one into Astra.

I'll post the responses we got as separate comments. These can serve as a basis for further discussion.

We are porting Rewatch to OCaml as a drop-in for the Rust version. Next I want to see whether in-process bsc is worth it: stop spawning a bsc process per module, and ideally stop writing cmj/cmt (and maybe cmi) to disk at all.

Do not implement yet. Think this through with me.

Context:

  • A lot of build time is process creation and artifact I/O, not typechecking.
  • Integration might be >2x. I want a dirty prototype that measures that, even if it is incorrect and single-threaded.
  • The compiler has lots of global/shared mutable state (Clflags, Config.load_path, Env cache, Ident, Js_config, typechecker mutation, etc.). There are essentially no tests that reuse one compiler process across modules.
  • Getting rid of global state is probably much easier than the Rewatch port, but only if we know what to reset/isolate.
  • No multicore required for the prototype. Sequential in-process with no cm* writes may already be faster.
  • A real compiler service / parallel-from-one-process comes later.

Please:

  1. Survey how bsc is invoked today (parse vs compile), what it reads/writes (ast, cmi, cmj, cmt, js), and which globals would leak across compilations.
  2. Propose the smallest prototype that can give a real speedup signal on stdlib + tests (or a real project). What can stay on disk? What must be in memory? What must be reset between modules?
  3. Argue whether that prototype is the right next step, or whether something else is better (reset-and-reuse API, keep writing cmi only, compiler service still spawning-free but still on disk, etc.).
  4. Explicitly list what is likely to go well, what is likely to go wrong, and how we would get fooled by a misleading benchmark.
  5. Recommend a concrete goal we could later implement with /goal.
Vorherrschende Sprache
ReScript
Sterne
7.5k
Forks
483
Ø Merge
1 T. 4 Std.
Gemergte PRs (30 T.)
130

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus rescript-lang/rescript

Alle Issues in rescript-lang/rescript

Ähnliche Issues

Weitere Issues zu Build System

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.