[MDEV-33181] Performance schema introduces many conditional branches even when disabled at runtime Created: 2024-01-04 Updated: 2024-01-04 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Performance Schema |
| Affects Version/s: | 5.5 |
| Fix Version/s: | 11.5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | performance | ||
| Issue Links: |
|
||||||||
| Description |
|
Unless MariaDB is built with cmake -DPLUGIN_PERFSCHEMA=NO, there will be some measurable overhead related to some frequently invoked operations, such as mysql_mutex_lock() and mysql_mutex_unlock(). Take the latter for example. It would resolve to the following inline function:
The call to pfs_unlock_mutex_v1() via the function pointer PSI_MUTEX_CALL(unlock_mutex), as well as the condition preceding that call are executed within the critical section of the mutex. It would be better to make use of function pointers, say,
and make the function pointer PSI_server->unlock_mutex point to either pthread_mutex_unlock or pfs_unlock_mutex(). If the server is compiled with PLUGIN_PERFSCHEMA=NO, the macro can resolve bypass the function pointer, something like this:
The function pointer would be set to pthread_mutex_unlock by static initialization, and assigned to the instrumented function at the end of pfs_init_func(). In this way, if the performance schema is disabled at runtime, mysql_mutex_unlock() would translate to a simple call to pthread_mutex_unlock() via a function pointer. While we are at it, I would also consider removing memory bloat like this:
Which binary compatibility is this about? To my knowledge, all plugins are typically included in the MariaDB Server repository and compiled from source code. |
| Comments |
| Comment by Marko Mäkelä [ 2024-01-04 ] |
|
With regard to mutexes, this would be a follow-up to |