> Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern. P…
As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE
It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue.
> If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done.
(Disclaimer: I'm not the one doing the work mentioned below)
It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far.
The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place.
We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: https://jnthn.net/papers/2019-gpw-ea.pdf
In short, there's a ton of stuff to do and it's being done.