Use inventory for static ingredient registration#934
Conversation
✅ Deploy Preview for salsa-rs canceled.
|
|
|
||
| input.items.push(parse_quote! { | ||
| #[cold] | ||
| #[inline(never)] |
There was a problem hiding this comment.
This was previously marked as inline(always), but it's only called in the slow path for both single and multi-database use cases.
CodSpeed Performance ReportMerging #934 will improve performances by 29.04%Comparing Summary
Benchmarks breakdown
|
| IngredientCache::<I>::UNINITIALIZED, | ||
| packed, | ||
| Ordering::Release, | ||
| Ordering::Relaxed, |
There was a problem hiding this comment.
I relaxed the failure ordering here because we don't synchronize on failure. FWIW this compare_exchange could even just be a store because it encapsulates all the cached data, but it doesn't really matter.
502e237 to
fab2734
Compare
|
I believe the benchmark results are somewhat misleading here because they use multiple databases. The fast path for accessing an ingredient is affected less (it doesn't include the |
|
Hmm looks like Miri doesn't support this yet rust-lang/miri#450. That might be the dealbreaker I was anticipating. |
|
There are also many projects out there that ban life-before-main including inventory for various reasons including linker issues. For example, if salsa used inventory, we would never be able to import it into the Android codebase. |
| ) -> &$zalsa::interned::IngredientImpl<$Configuration> { | ||
| let zalsa = db.zalsa(); | ||
| $INTERN_CACHE.get_or_create(zalsa, || { | ||
| <dyn $Db as $Db>::zalsa_register_downcaster(db); |
There was a problem hiding this comment.
I'm not exactly sure why this was here before, I don't think it's necessary. It's clearer now because we register the downcaster on the function ingredient directly.
I think the ideal approach would be to make this an optional feature, and users who can't use inventory can register ingredients manually instead. Out of curiosity, does the Android codebase support |
2fff0f3 to
407f43b
Compare
|
I added a simple API for manual ingredient registration. This is just blocked on rust-lang/miri#4459 for Miri support (to avoid rewriting all of our tests to use manual registration). |
407f43b to
842d7c2
Compare
| // It doesn't matter if we overwrite any stores, as `create_index` should | ||
| // always return the same index. | ||
| self.ingredient_index | ||
| .store(ingredient_index.as_u32(), Ordering::Release); |
There was a problem hiding this comment.
I'm not sure this is guaranteed when using manual registration because different databases can have different registered ingredients.
There was a problem hiding this comment.
Hmm you're right. I guess we still need the nonce check when the inventory feature is disabled? You shouldn't be able to register any ingredients manually that weren't already registered when inventory is enabled.
There was a problem hiding this comment.
Hmm, this does mean that our inventory feature isn't strictly addeditve because you won't be able to use the manual registration functions when using inventory (or you can, they're just ignored)
There was a problem hiding this comment.
With the inventory feature you can't create an ingredient except that it's automatically registered.
9cd1cc8 to
678609e
Compare
678609e to
901868e
Compare
There was a problem hiding this comment.
Nice. This is awesome.
I wonder if this also fixes the non-determinism when replaying multithreaded tests.
Requesting review from David/Lukas to get a thumbs up/down from the r-a side
Do you know how far off the miri changes are? Also, have you tested if the ty playground wroks with this new salsa version?
davidbarsky
left a comment
There was a problem hiding this comment.
given that miri supports this + this is a substantial speedup, i think we're okay with landing this. if we run into issues, well, we know where to report.
## Summary Pulls in salsa-rs/salsa#934.
## Summary Pulls in salsa-rs/salsa#934.
Salsa currently registers ingredients dynamically the first time they are accessed, but persistent caching will require that all serializable ingredients are registered up-front. It's possible that we may switch to a static ingredient registration API, but as a first step, we can use
inventoryto ensure all ingredients have stable indices. This should enable persistent caching and also give us the same performance benefits of static ingredient registration without a large breaking API change.Inventory has pretty good platform support, I believe it includes all the platforms we care about. There is a caveat on WebAssembly, but I don't think it's a dealbreaker.