4 ms·
Hi folks, I work on the Pyrefly team at Meta. Our FAQ covers a good number of the questions raised here: https://pyrefly.org/en/docs/pyrefly-faq/ https://pyref
by team_pyrefly 1y ago
Hi folks, I work on the Pyrefly team at Meta. Our FAQ covers a good number of the questions raised here: https://pyrefly.org/en/docs/pyrefly-faq/ https://pyrefly.org/en/docs/pyrefly-faq/. I can also try to answer some of your questions. Thanks for taking a look!
- muglug 1y agoAt Slack we have an internal Rust-based Hack typechecker that’s about 20% faster than the OCaml one (we use both) Did you see better speedups over Pyre? Aka did I leave stuff on the table…
- samwgoldman 1y agoHack is quite a bit more optimized than Pyre was, but Pyrefly is at least 10x faster than Pyre on the IG codebase. I didn’t know about the Rust-based Hack checker— that’s really cool!
- muglug 1y agoWhere do those speed ups come from? 10x seems extraordinary for a task that’s pretty IO-bound. Was Pyre ineffectively parallelised or something?
- CoolCold 1y agoIO bound, how you define that? From my perspective, modern consumer grade SSDs/NVMes producing 7GB/s-8GB/s (yep, Giga Byte per second) for reads gives me 1/7-1/8 of second to load that data in RAM the rest of the 1 second is for CPU.
- muglug 1y ago"pretty" was doing too much work, but there's the twin cost of reading and parsing the file, which usually needs to be done twice (once for static reflection, and once for analysis). The reading and parsing eats up about 16% of the analysis phase, and slightly more overall — maybe 20% of the total runtime.
- fastball 1y agoParsing is not IO and clearly an area you can get much better performance in-program.