refactor(perf): Remove extra page indirection in Table#710
refactor(perf): Remove extra page indirection in Table#710Veykril merged 1 commit intosalsa-rs:masterfrom
Table#710Conversation
✅ Deploy Preview for salsa-rs canceled.
|
CodSpeed Performance ReportMerging #710 will degrade performances by 3.29%Comparing Summary
Benchmarks breakdown
|
|
Results look promising |
85ebb05 to
5ba9ff5
Compare
|
Alright all cleaned up, this will collide with #649 |
TableTable
5ba9ff5 to
1a8456e
Compare
|
We could likely give |
1a8456e to
da5d96b
Compare
bbebda9 to
54fc519
Compare
54fc519 to
2ae5f93
Compare
| let index = self.allocated.load(Ordering::Acquire); | ||
| if index == PAGE_LEN { | ||
| let _guard = self.0.allocation_lock.lock(); | ||
| let index = self.0.allocated.load(Ordering::Acquire); |
There was a problem hiding this comment.
Given we only ever modify allocated in this function while the allocation_lock is held, could we use Relaxed ordering for the load here ? I believe so as the lock call should already incur a happens-before relationship for the participating threads right?
There was a problem hiding this comment.
In fact it should be fine to make all loads (and the store in the critical section) relaxed due to the sole store happening within the critical section right? (not gonna include this in the PR either way)
cf213ee to
f99f889
Compare
TableTable
f99f889 to
4b6dde4
Compare
|
I like the new lower limit, it makes my PRs pop out more now :^) |
TableTable
69b610b to
0c7e678
Compare
|
Unsure why this is regressing in one benchmark after rebasing to latest now. Looks like noise to me as there isn't anything special happening in that regressed codepath |
0c7e678 to
aa04ba6
Compare
aa04ba6 to
549f8a4
Compare
By manually erasing the concrete slot types and dealing with the vtable ourselves
549f8a4 to
22a9032
Compare
|
We discussed this in the sync meeting and deciding that the result still seems worth it overall. I have acknowledged the regression. |
By manually erasing the concrete slot types and dealing with the vtable ourselves