# Polonius, borrow checking performance & progressive intelligence **URL:** \ **Category:** compiler\ **Created:** [January 30, 2025, 4:31pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298 "2025-01-30T16:31:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![vlovich](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/vlovich/32/12106_2.png) [@vlovich](https://internals.rust-lang.org/u/vlovich)\ **Post date:** [January 30, 2025, 4:31pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/1 "2025-01-30T16:31:16Z")
Basically the inspiration for this topic is tiered JIT where you only expand effort when you need it rather than every where. One of the slow downs for stabilizing Polonius from what I’ve read & listened to seems to be about making it work with minimal performance impact. I was wondering if there’s been any thought about progressive layers of borrow checkers where simple and fast algorithms can validate the more common simple cases but failing to validate with them triggers a check with the next tier about whether the code is still valid Rust. The most complicated code would compile more slowly but the much more common simple code would validate trivially. Of course, this is predicated on the assumption that the simpler borrow checker could produce an equivalent state update of the lifetime graph, but I think that’s likely true and not where the complexity lies. ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [January 30, 2025, 4:38pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/2 "2025-01-30T16:38:51Z")
The plan is exactly to run location-insensitive Polonius first as it is faster and only run location-sensitive Polonius when location-insensitive Polonius reports an error. ---
**Author:** ![HKalbasi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hkalbasi/32/7938_2.png) [@HKalbasi](https://internals.rust-lang.org/u/HKalbasi)\ **Post date:** [January 30, 2025, 6:22pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/3 "2025-01-30T18:22:44Z")
A related idea: Start code generation as soon as type checking is completed, defer borrow checking to another job. Make borrow checking jobs low priority, so that they will be executed when there is free core (for example in linking). So borrow checking will become almost free in a machine with many cores. ---
**Author:** ![pitaj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pitaj/32/11262_2.png) [@pitaj](https://internals.rust-lang.org/u/pitaj)\ **Post date:** [January 30, 2025, 7:03pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/4 "2025-01-30T19:03:43Z")
That doesn't help the very common `cargo check` case, though. Which I'd argue is more important. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [January 30, 2025, 9:57pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/5 "2025-01-30T21:57:07Z")
> [@HKalbasi](#): > > Make borrow checking jobs low priority, so that they will be executed when there is free core (for example in linking). Hmm, while I don't think that with the current pipelining this would be a good idea -- after all, codegen already doesn't block downstream crates -- it makes me wonder a different approach to pipelining that's willing to emit an rlib without having completed some of the checks yet. If we have any checking passes that strictly do not modify things, maybe we could run that _after_ emitting enough to let pipelined compilation continue. For example, we could check that all the item `const`s can be evaluated only after emitting the rlib -- it'd still fail compilation _eventually_ if CTFE for them fails, but in the common case of dependencies that are going to pass anyway it could let pipelining kick off the next phase just that little bit sooner. (Maybe even some coherence checks could be delayed like that? Obviously type inference can't be, though, since that's not a check that's a critical part of things like resolution.) ---
**Author:** ![lqd](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/lqd/32/2785_2.png) [@lqd](https://internals.rust-lang.org/u/lqd)\ **Post date:** [January 31, 2025, 4:08pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/6 "2025-01-31T16:08:34Z")
That's what we have in the `-Zpolonius` datalog implementation today: it only does a full analysis if the location-insensitive analysis says there are "possible errors". I feel you described the spirit of it, but I'll slightly expand it for clarity and details, as we want a bit more with the `-Zpolonius=next` implementation: we want each level of detail to not only increase precision, but to also prune the tree for the next levels, so that the higher precision applies only on less data. (You can think of it as different "grades" or quality levels, and so I call this "graded borrow-checking") I had prototypes of this in the datalog implementation, that's why we're hopeful about it -- and are currently discussing how to realize it in-tree. We know it is better, but don't yet know if it is _enough_ :). ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [July 25, 2026, 4:08pm UTC](https://internals.rust-lang.org/t/polonius-borrow-checking-performance-progressive-intelligence/22298/7 "2026-07-25T16:08:36Z")
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.