Improve handling of indexed types #35
Comments
|
Ideally, instead of duplicating that logic per type, we'd find something that provides this behaviour on crates.io or we write our own helper |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 10, 2023
In smir use `FxIndexMap` to store indexed ids Previously we used `vec` for storing indexed types, which is fine for small cases but will lead to huge performance issues when we use `smir` for real world cases. Addresses rust-lang/project-stable-mir#35 r? `@oli-obk`
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Oct 10, 2023
In smir use `FxIndexMap` to store indexed ids Previously we used `vec` for storing indexed types, which is fine for small cases but will lead to huge performance issues when we use `smir` for real world cases. Addresses rust-lang/project-stable-mir#35 r? ``@oli-obk``
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 10, 2023
Rollup merge of rust-lang#116560 - ouz-a:efficient_ids, r=oli-obk In smir use `FxIndexMap` to store indexed ids Previously we used `vec` for storing indexed types, which is fine for small cases but will lead to huge performance issues when we use `smir` for real world cases. Addresses rust-lang/project-stable-mir#35 r? ``@oli-obk``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently our implementation of indexed types such as
AllocId,DefId, and soon rust-lang/rust#115772Spanrelies on https://github.com/rust-lang/rust/blob/master/compiler/rustc_smir/src/rustc_internal/mod.rs#L141-L154 this kind of brute way of doing things, this is fine for our small use cases but @oli-obk thinks and suggests this is going to be a problem in the future when we face real-world use cases where thousands of ids will be iterated, they suggest we should add a hasmap from value to index per table to improve our handling of these types.The text was updated successfully, but these errors were encountered: