Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Rewatch: in-process bsc prototype

Đang mở
  • Có gì không ổn?
#8,659 2 bình luận 2 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
ocaml
Lĩnh vực
build-system, compilers, performance

Hướng nghiên cứu

Bắt đầu với việc triển khai lại OCaml Rewatch từ #8653 và theo dõi cách tệp thực thi bsc được gọi cho các bước phân tích cú pháp và biên dịch, bao gồm cả các bản build của stdlib và test. Ghi lại các tạo tác và trạng thái dùng chung có liên quan, sau đó xác định một benchmark nguyên mẫu tuần tự và một khuyến nghị cụ thể về mục tiêu mà một triển khai sau này nên hướng tới.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
OCaml
Star
7.5k
Fork
484
Merge trung bình
19 giờ 40 phút
Pull request đã merge (30 ngày)
54

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rescript-lang/rescript

Tất cả issue của rescript-lang/rescript

Issue tương tự

Thêm issue về Build System

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.