The slowdown in peformance was seen while benchmarking MDEV-21580.
This is where one can check the slowdown for varchar(200) utf8

https://jira.mariadb.org/browse/MDEV-21784?focusedCommentId=146126&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-146126

So without the patch

MariaDB [benchmarks]> select table_size, test_time_ms from test_runs;

+------------+--------------+

| table_size | test_time_ms |

+------------+--------------+

|      25000 |           43 |

|      50000 |           85 |

|     100000 |          215 |

|     500000 |         1077 |

|    1000000 |         2440 |

|    2000000 |         4865 |

|    4000000 |        11245 |

+------------+--------------+

With the patch where we pack addon fields:

MariaDB [benchmarks]> select table_size, test_time_ms from test_runs;

+------------+--------------+

| table_size | test_time_ms |

+------------+--------------+

|      25000 |           24 |

|      50000 |           57 |

|     100000 |          111 |

|     500000 |          548 |

|    1000000 |         1213 |

|    2000000 |         2465 |

|    4000000 |         4868 |

+------------+--------------+

Patch
http://lists.askmonty.org/pipermail/commits/2020-March/014209.html

I'm debugging this example:

create table t20 (a varchar(200) character set utf8, b int);

insert into t20 select seq,seq from seq_1_to_10;

select * from t20 order by a;

in filesort_use_addons():

  return *length + sortlength <

         table->in_use->variables.max_length_for_sort_data;

Here, sortlength=401, *length=609.

401 is the length of strxfrm() image of the column. That is, we assume non-packed sort keys here.
(note that try_to_pack_sortkeys() hasn't been called yet and we don't actually know)

Then, execution enters Sort_param::try_to_pack_sortkeys() and at the end of that function it sets:

  rec_length= sort_length + addon_length;

Here, sort_length = 607, addon_length = 609.

Then, execution enters Sort_param::try_to_pack_addons(), where the check

  if (rec_length + sz > max_length_for_sort_data) {

fails, because rec_length=1216 while max_length_for_sort_data=1024 (sz=2 but that doesn't matter).

Does filesort_use_addons() do wrong computation?

One may argue that this computation is fine, because:

use of unpacked key length in filesort_use_addons() is fine, because unpacked key length is a good upper bound or packed key length. (One can expect the code to not switch to packed keys if they are bigger than unpacked ones).

The second check fails, because we are using maximum possible length of the packed sort key there. For utf8_general_ci, the original string form can be longer than its mem-comparable form (note that this is rarely achieved in practice. Also note that for other collations, e.g. utf8_unicode_ci, this is not the case).