Interesting thread from this summer: https://www.reddit.com/r/perl6/comments/8p26bb/is_perl6_fast...
https://github.com/rakudo/rakudo/search?o=desc&q=fast&s=comm...
That's just the compiler rather than VM or NQP level, where you will see even more performance related work.
One of the bigger breaking changes in 6.D at the language spec level is for performance of scheduling multi threaded work. https://github.com/rakudo/rakudo/pull/1004
The main canary test for performance used by the community is the Text::CSV module. The vanilla Raku implementation is about 2x slower than the C wrapping Perl equivalent. The nice property of the Raku library is you can run it in parallel quite trivially and then its suddenly faster than the Perl version. In general the simple introduction of hyper/race keywords into user code is a big win for performance, but perhaps not cost.
There are a tonne of features of the language specific for performance most people walking through the door aren't so aware of. Native type decorating your code and variables for example, usually invokes significant improvements to numeric work. The JIT does some of that automagically but simple issues like your code implicitly switching between rational and floating point types will break optimisation. If you don't say what you really want to do Raku always assumes you want to do the safest and usually slowest thing like use bignum or rational type things, that are harder to speed up down at the CPU.
Performance and Python aren't exactly related (I know you can call into C code with numpy etc., but still Python itself and idiomatic code in it is often super slow).