Conversation
l_find(): Specialize the two distinct cases: callback or key. The callback is only used by lf_hash_iterate(), which can be a very CPU intensive function, especially in ReadView::open(). Now that the callback variant uses much fewer parameters and can be expanded inline, InnoDB trx_sys.rw_trx_hash iterations in ReadView::open() and elsewhere should become faster.
|
|
|
Dunno, it must bring some measurable performance improvement to make this code duplication worthy. Most probably it won't improve performance enough to consider those two famous jira issues fixed. |
|
Yes @dr-m , please run the benchmarks, there are prominently featured in the bug report. And share your numbers. We can't guess whether it fixes anything. It needs confirmation before review, and most important, it should give you this confirmation. Not "This should be best tested by HammerDB or Sysbench", but "I tested and it brought 0.0002% performance improvement" or something similar |
|
This comment in MDEV-21423 covers a test scenario that @vaintroub requested. I am observing an improvement of 3% in throughput in my test environment. The largest difference on this system that I observed was 9%, but that was in a shorter run. |
4 participants
Description
The function
lf_hash_iterate()can be very CPU intensive, especially inReadView::open().l_find(): Specialize the two distinct cases: callback or key lookup. The callback is only used bylf_hash_iterate().Now that the callback variant of
l_find()uses much fewer parameters and can be expandedinline, InnoDBtrx_sys.rw_trx_hashiterations inReadView::open()and elsewhere should become faster.Release Notes
See the previous section.
How can this PR be tested?
This low-level code should be well covered by the existing regression tests. Pretty much any InnoDB test should invoke
ReadView::open()or some MDL, which are some users of this code.This should be best tested by HammerDB or Sysbench, using
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;so that calls to
ReadView::open()will be more frequent.Basing the PR against the correct MariaDB version
mainbranch.This performance bug fix is also applicable to the 10.6 branch. However, according to our current policy we only fix crash or corruption bugs in the 10.6 branch.