It seems like it is fixed properly now. See this discussion:
https://irclog.perlgeek.de/perl6-dev/2018-03-01#i_15872426
On 2017-10-22 08:28:20, c...@zoffix.com wrote:
> On Tue, 26 Sep 2017 11:03:11 -0700, c...@zoffix.com wrote:
> > On Thu, 22 Jun 2017 10:29:59 -0700, c...@zoffix.com wrote:
> > > I'd expect the fancy Unicode versions of <=, >=, and != to perform
> > > equally well, instead the
> > > ≥ and ≤ are 36x slower than their Texas companions and ≠ is 15x
> > > slower.
> > >
> > > Here's the timings for >= vs ≥:
> > >
> > > m: my $x = rand; for ^1000_000 { $ = $x >= 1_000_000_000_000 }; say
> > > now - INIT now;
> > > rakudo-moar 43c176: OUTPUT: «0.74663187»
> > > m: my $x = rand; for ^1000_000 { $ = $x ≥ 1_000_000_000_000 }; say
> > > now
> > > - INIT now;
> > > rakudo-moar 43c176: OUTPUT: «(timeout)»
> > > m: my $x = rand; for ^1000_0 { $ = $x ≥ 1_000_000_000_000 }; say
> > > now
> > > -
> > > INIT now;
> > > rakudo-moar 43c176: OUTPUT: «0.2661272»
> > > m: say 0.2661272*100 / 0.729002
> > > rakudo-moar 43c176: OUTPUT: «36.505689»
> >
> >
> > So I made the static optimizer change Mexico ops to Texas versions,
> > so
> > this problem no longer exist. So, should the ticket be closed?
> >
> > Fixed in https://github.com/rakudo/rakudo/commit/6ec21cb473
> >
> > I tried writing a test, but couldn't get anything usable. My attempt
> > was this:
> >
> > use Test;
> > subtest 'performance of ≤, ≥, ≠ compared to Texas versions' => {
> > sub measure (&code) { code for ^300; with now { code for
> > ^100_000;
> > now - $_ } }
> >
> > is-approx { rand ≤ rand }.&measure, { rand <= rand }.&measure, '≤',
> > :rel-tol<.5>;
> > is-approx { rand ≥ rand }.&measure, { rand >= rand }.&measure, '≥',
> > :rel-tol<.5>;
> > is-approx { rand ≠ rand }.&measure, { rand != rand }.&measure, '≠',
> > :rel-tol<.5>;
> > }
>
>
> So the optimizer fix didn't do a full job. There were still cases that
> ended up 86x slower:
>
> When chained:
>
> <Zoffix__> m: $ = rand ≤ rand ≤ rand for ^100_000; say now - INIT now
> <camelia> rakudo-moar a042fd927: OUTPUT: «2.91023964»
> <Zoffix__> m: $ = rand <= rand <= rand for ^100_000; say now - INIT
> now
> <camelia> rakudo-moar a042fd927: OUTPUT: «0.094577»
>
> Or when user defines their own version of the ASCII op:
>
> <Zoffix__> m: $ = rand ≤ rand for ^100_000; say now - INIT now
> <camelia> rakudo-moar a042fd927: OUTPUT: «0.0474443»
> <Zoffix__> m: class Foo {}; sub infix:«<=» (Foo, Foo) {}; $ = rand ≤
> rand for ^100_000; say now - INIT now
> <camelia> rakudo-moar a042fd927: OUTPUT: «1.94282032»
>
> Some proposed to substitute Unicode versions for Texas ones during
> parsing and codegen, but the only way I
> know how to do that would make user's use of `≠` use a custom `!=` op,
> if one exists.
>
> It's possible we *do* want to declare that we do such aliasing: a
> Unicode op is just a grammatical alias
> to the ASCII op and gets rewritten to it. If there's a consensus to do
> that, it should be done for all the ops,
> even ones that don't have this performance issue (which is due to
> capture slipping).
>
> For now, I basically restored lizmat++'s original fix adding whatever
> datish ops that were
> originally missing as well:
> https://github.com/rakudo/rakudo/commit/6ad06fad9f
