Details
-
Epic
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
Performance: micro optimizations
Description
In MariaDB there seem to be no major (>5%) bottlenecks for CPU bound workloads. However there's a whole bunch of more or less easily fixable minor things that waste inexcusable amount of time. Among those:
- one-line virtual methods that can't be inlined
- simple functions defined in source file that can't be inlined
- abuse of likely()/unlikely() (likely in InnoDB, PFS)
- added (sometimes complex) conditions (PFS, WSREP, PROFILING)
- frequent calls of pthread_getspecific() (InnoDB, parser, optimizer)
See linked issues for details.
Attachments
Activity
I suspect that the various inline_mysql_ functions in include/mysql/psi/mysql_thread.h can lead to serious code bloat when the performance schema is compiled in. I partially worked around those in MDEV-21452 for the popular lock_sys.mutex and dict_sys.mutex by defining an explicitly non-inlined entry point like this:
#ifdef HAVE_PSI_MUTEX_INTERFACE
|
/** Try to acquire lock_sys.mutex */ |
ATTRIBUTE_NOINLINE int mutex_trylock(); |
/** Acquire lock_sys.mutex */ |
ATTRIBUTE_NOINLINE void mutex_lock(); |
/** Release lock_sys.mutex */ |
ATTRIBUTE_NOINLINE void mutex_unlock(); |
#else
|
/** Try to acquire lock_sys.mutex */ |
int mutex_trylock() { return mysql_mutex_trylock(&mutex); } |
/** Aqcuire lock_sys.mutex */ |
void mutex_lock() { mysql_mutex_lock(&mutex); } |
/** Release lock_sys.mutex */ |
void mutex_unlock() { mysql_mutex_unlock(&mutex); } |
#endif |
Duplicating complex inline functions not only makes the executable bigger (and thus makes instruction cache misses more likely) as was the case in MDEV-22721. In this case the duplication could also make branch prediction harder.
Since it was agreed to keep performance schema intact, further analysis will be done with performance schema compiled out.