Add experimental programmatic API for Monty - #4866
Closed
yangdanny97 wants to merge 5 commits into
Closed
yangdanny97 wants to merge 5 commits into
yangdanny97 wants to merge 5 commits into
Conversation
Contributor
|
This pull request has been imported. If you are a Meta employee, you can view this in D119299371. (Because this pull request was imported automatically, there will not be any future comments.) |
This comment has been minimized.
This comment has been minimized.
kinto0
requested changes
Sep 9, 2026
Collaborator
Author
|
In my view this is in the same category as glean's API or the WASM stuff, where it should be undocumented until we refine the API enough and decide to publicize it The main purpose of merging it is so that Monty can actually release a version that uses Pyrefly |
Collaborator
Author
|
Cleaned up a few things |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
kinto0
approved these changes
Sep 11, 2026
kinto0
left a comment
kinto0
left a comment
Contributor
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
stroxler
approved these changes
Sep 22, 2026
stroxler
left a comment
stroxler
left a comment
Contributor
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
Contributor
meta-codesync Bot
pushed a commit
that referenced
this pull request
Sep 25, 2026
Summary: I took a look at https://github.com/pydantic/monty/pull/501/changes Running with the latest Pyrefly commit, it seems that perf numbers have regressed with respect to ty. However, Claude suggested this simple fix to `embed.rs` (introduced by yangdanny97 in #4866) which closes the gap. From Claude: > A check solves one target module over a few small in-memory modules, so the thread pool has nothing to parallelise; dispatching to it and waiting on a futex dominated the cost of a changed-input check (~1.8ms vs ~47us inline on a 20-thread machine). It also meant every embedder process got a pool sized to the machine. > `embed::Checker::new` builds its `State` with `ThreadCount::default()`, which is `AllThreads`. Each `check()` solves one target module over > a few small in-memory modules, so the pool has nothing to parallelise, and dispatching to rayon and waiting on it costs far more than the > check itself. This PR switches the checker to `ThreadCount::Inline`. > > Numbers are from Monty's type-checking benchmarks (one `Checker::check` per iteration), measured with criterion on a 20-thread Linux > machine: > > | Benchmark | Before | After | Speedup | > |---|---|---|---| > | `warm_varying` | 2.09 ms | 48.5 µs | 43× | > | `warm_varying_50stubs` | 1.97 ms | 160 µs | 12× | > | `repl_sequence` | 8.76 ms | 500 µs | 17× | > | `repl_sequence_200` | 548 ms | 163 ms | 3.4× | > > - `warm_varying`: a one-line snippet that changes on every call > - `warm_varying_50stubs`: the same, importing a 50-line stub module > - `repl_sequence` / `_200`: 4 or 200 REPL steps, with the stubs growing each step > > Before this change, the overhead depends on how many cores the process can use: `warm_varying` takes 2.09 ms on 20 cores, 726 µs on 4 and 68 > µs on 1 (pinned with `taskset`), compared with 48.5 µs inline. So the cost of a check tracks the machine's core count, not the work done. > Embedders that run several checkers at once (Monty runs one per sandbox worker process) also get a full-size pool for each checker. Fixes #XXXX Pull Request resolved: #5022 Reviewed By: connernilsen Differential Revision: D121780342 fbshipit-source-id: 074768e58238fac8af4cccc90b9f0462328a5b6b
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
For https://www.github.com/pydantic/monty/pull/501
Something about how Monty can't depend on a crate that's a GH revision hash.
I guess after this gets merged you guys need to publish it, but IDK how to do that
Test Plan
I ran all the tests at some point but after the demise of my Macbook Pro I now use a Macbook Air which has no fans so I'm reluctant to risk running the test suite and overheating it
so, TLDR trust CI