Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4309

DBT-3 Q1 benchmark: Benchmark + profile a patch

Details

    Description

      I need a benchmark and a profiling run: mariadb-5.5-latest vs mariadb-5.5-latest with attached patch.

      DBT-3, MyISAM.

      Attachments

        Issue Links

          Activity

            Benchmark results from Axel, with a few plots added.

            psergei Sergei Petrunia added a comment - Benchmark results from Axel, with a few plots added.

            Looking at the data, one sees that only the original Q1 benefits from the patch. For other queries, the difference between medians is too small when compared to stddev. Value distribution charts (see attached file) also do not show a difference.

            psergei Sergei Petrunia added a comment - Looking at the data, one sees that only the original Q1 benefits from the patch. For other queries, the difference between medians is too small when compared to stddev. Value distribution charts (see attached file) also do not show a difference.

            The reason for this is: field_conv() is only executed by the query that uses a GROUP BY.

            Queries without group by do not run field_conv(), and so do not benefit from the patch.

            Stacktrace of where we hit field_conv:

            Breakpoint 1, field_conv (to=0xd49d618, from=0xd4978a8) at /home/psergey/dev2/5.5/sql/field_conv.cc:829
            (gdb) wher
            #0 field_conv (to=0xd49d618, from=0xd4978a8) at /home/psergey/dev2/5.5/sql/field_conv.cc:829
            #1 0x0840c94b in save_field_in_field (from=0xd4978a8, null_value=0xd48acfb, to=0xd49d618, no_conversions=true) at /home/psergey/dev2/5.5/sql/item.cc:5795
            #2 0x0840cc3a in Item_field::save_org_in_field (this=0xd48acb8, to=0xd49d618) at /home/psergey/dev2/5.5/sql/item.cc:5807
            #3 0x08272910 in end_update (join=0xd48e240, join_tab=0xd48f4a0, end_of_records=false) at /home/psergey/dev2/5.5/sql/sql_select.cc:17618
            #4 0x08270aef in evaluate_join_record (join=0xd48e240, join_tab=0xd48f298, error=0) at /home/psergey/dev2/5.5/sql/sql_select.cc:16496
            #5 0x0827dde9 in sub_select (join=0xd48e240, join_tab=0xd48f298, end_of_records=false) at /home/psergey/dev2/5.5/sql/sql_select.cc:16277
            #6 0x08281149 in do_select (join=0xd48e240, fields=0x0, table=0xd49bb18, procedure=0x0) at /home/psergey/dev2/5.5/sql/sql_select.cc:15947
            #7 0x082985bd in JOIN::exec (this=0xd48e240) at /home/psergey/dev2/5.5/sql/sql_select.cc:2405
            #8 0x08294034 in mysql_select (thd=0xd47f108, rref_pointer_array=0xd480d34, tables=0xd48d808, wild_num=0, fields=..., conds=0xd48dd28, og_num=4, order=0xd48e0a0, group=0xd48ded0, having=0x0, proc_param=0x0, select_options=2147748608, result=0xd48e230, unit=0xd480744, select_lex=0xd480bf4) at /home/psergey/dev2/5.5/sql/sql_select.cc:3062

            psergei Sergei Petrunia added a comment - The reason for this is: field_conv() is only executed by the query that uses a GROUP BY. Queries without group by do not run field_conv(), and so do not benefit from the patch. Stacktrace of where we hit field_conv: Breakpoint 1, field_conv (to=0xd49d618, from=0xd4978a8) at /home/psergey/dev2/5.5/sql/field_conv.cc:829 (gdb) wher #0 field_conv (to=0xd49d618, from=0xd4978a8) at /home/psergey/dev2/5.5/sql/field_conv.cc:829 #1 0x0840c94b in save_field_in_field (from=0xd4978a8, null_value=0xd48acfb, to=0xd49d618, no_conversions=true) at /home/psergey/dev2/5.5/sql/item.cc:5795 #2 0x0840cc3a in Item_field::save_org_in_field (this=0xd48acb8, to=0xd49d618) at /home/psergey/dev2/5.5/sql/item.cc:5807 #3 0x08272910 in end_update (join=0xd48e240, join_tab=0xd48f4a0, end_of_records=false) at /home/psergey/dev2/5.5/sql/sql_select.cc:17618 #4 0x08270aef in evaluate_join_record (join=0xd48e240, join_tab=0xd48f298, error=0) at /home/psergey/dev2/5.5/sql/sql_select.cc:16496 #5 0x0827dde9 in sub_select (join=0xd48e240, join_tab=0xd48f298, end_of_records=false) at /home/psergey/dev2/5.5/sql/sql_select.cc:16277 #6 0x08281149 in do_select (join=0xd48e240, fields=0x0, table=0xd49bb18, procedure=0x0) at /home/psergey/dev2/5.5/sql/sql_select.cc:15947 #7 0x082985bd in JOIN::exec (this=0xd48e240) at /home/psergey/dev2/5.5/sql/sql_select.cc:2405 #8 0x08294034 in mysql_select (thd=0xd47f108, rref_pointer_array=0xd480d34, tables=0xd48d808, wild_num=0, fields=..., conds=0xd48dd28, og_num=4, order=0xd48e0a0, group=0xd48ded0, having=0x0, proc_param=0x0, select_options=2147748608, result=0xd48e230, unit=0xd480744, select_lex=0xd480bf4) at /home/psergey/dev2/5.5/sql/sql_select.cc:3062

            There are two calls to field_conv() made for each row, because GROUP BY list has two elements:

            group by l_returnflag, l_linestatus

            The fields have the same types (both are CHAR(1) nullable), hence field_conv() calls proceed on the same route.

            Before the patch,
            field_conv() made the following virtual function calls:

            Breakpoint 4, field_conv (to=0xd49d610, from=0xd4978a0) at /home/psergey/dev2/5.5/sql/field_conv.cc:829
            Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::real_type (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1620
            Field::pack_length (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:286
            Field::pack_length (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:286
            Field_str::decimals (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:735
            Field_str::decimals (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:735
            Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_str::charset (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:745
            Field_str::charset (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:745
            Field_string::real_type (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:1662
            14 calls

            After the patch:
            Field_string::real_type (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::real_type (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:1662
            Field_string::type (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:1620
            Field::pack_length (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:286
            Field::pack_length (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:286
            Field_str::decimals (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:735
            Field_str::decimals (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:735
            Field_str::charset (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:745
            Field_str::charset (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:745
            9 calls

            We've managed to remove 5 out of 14 calls. There is a potential to remove another 9 calls, if we switch field_conv() from dynamic decision-making to static one.

            psergei Sergei Petrunia added a comment - There are two calls to field_conv() made for each row, because GROUP BY list has two elements: group by l_returnflag, l_linestatus The fields have the same types (both are CHAR(1) nullable), hence field_conv() calls proceed on the same route. Before the patch, field_conv() made the following virtual function calls: Breakpoint 4, field_conv (to=0xd49d610, from=0xd4978a0) at /home/psergey/dev2/5.5/sql/field_conv.cc:829 Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::real_type (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1620 Field::pack_length (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:286 Field::pack_length (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:286 Field_str::decimals (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:735 Field_str::decimals (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:735 Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::real_type (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_str::charset (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:745 Field_str::charset (this=0xd49d610) at /home/psergey/dev2/5.5/sql/field.h:745 Field_string::real_type (this=0xd4978a0) at /home/psergey/dev2/5.5/sql/field.h:1662 14 calls After the patch: Field_string::real_type (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::real_type (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:1662 Field_string::type (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:1620 Field::pack_length (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:286 Field::pack_length (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:286 Field_str::decimals (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:735 Field_str::decimals (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:735 Field_str::charset (this=0xd4978a8) at /home/psergey/dev2/5.5/sql/field.h:745 Field_str::charset (this=0xd49d618) at /home/psergey/dev2/5.5/sql/field.h:745 9 calls We've managed to remove 5 out of 14 calls. There is a potential to remove another 9 calls, if we switch field_conv() from dynamic decision-making to static one.

            Next step in attempt to make tmp table grouping faster.

            sanja Oleksandr Byelkin added a comment - Next step in attempt to make tmp table grouping faster.

            Benchmark results for 201303260107_sanja_copy_calls_patch.diff

            psergei Sergei Petrunia added a comment - Benchmark results for 201303260107_sanja_copy_calls_patch.diff

            Polished patch.

            sanja Oleksandr Byelkin added a comment - Polished patch.

            Review feedback provided for patch #2 over email.

            psergei Sergei Petrunia added a comment - Review feedback provided for patch #2 over email.

            Data from my 'pylon' machine. DBT3 sf=1, compile-pentium-max, Q1 as defined by Q1_virtfun_patch2-edited.ods. The patch is 201402181003_sanja_copy_calls_patch.diff.

            mariadb-5.5 vanilla - 4.81 sec (+/-0.02 sec)
            mariadb-5.5 + patch - 4.58 sec (+/- 0.02 sec) – The patch gives ~ 5% speedup.

            mariadb-10.0 vanilla - 5.30 (+/0 0.01 sec)
            mariadb-10.0 + patch - 5.28 (+/- 0.02 sec) – The patch 0.4% speedup, a barely noticeable difference.

            That is, there is speedup on 5.5 but not on 10.0, for some reason.

            psergei Sergei Petrunia added a comment - Data from my 'pylon' machine. DBT3 sf=1, compile-pentium-max, Q1 as defined by Q1_virtfun_patch2-edited.ods. The patch is 201402181003_sanja_copy_calls_patch.diff. mariadb-5.5 vanilla - 4.81 sec (+/-0.02 sec) mariadb-5.5 + patch - 4.58 sec (+/- 0.02 sec) – The patch gives ~ 5% speedup. mariadb-10.0 vanilla - 5.30 (+/0 0.01 sec) mariadb-10.0 + patch - 5.28 (+/- 0.02 sec) – The patch 0.4% speedup, a barely noticeable difference. That is, there is speedup on 5.5 but not on 10.0, for some reason.

            People

              sanja Oleksandr Byelkin
              psergei Sergei Petrunia
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.