Obviously, that fixes the immediate problem, but is there any clue as
to the reason for the extraordinary difference in performance? Where's
it happening?
I can see it taking longer for the parser to look up the characters,
but shouldn't the original translation have reduced that to a common
form
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 ^100
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 ^100
Temporarily fixed with a13bad95b2e1ad48a1d1a
> On 22 Jun 2017, at 22:59, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:
>
> This was discussed in
> https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342
>
> In theory, this ticket should apply for other ops as well.
>
> Note that
This was discussed in
https://github.com/rakudo/rakudo/pull/1032#issuecomment-284217342
In theory, this ticket should apply for other ops as well.
Note that I said that I will change the way unicode ops are implemented, but I
didn't have much time since then. Hoping to get to it at some point.
O
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131626]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131626 >
I'd expect the fancy Unicode versions of <=, >=, and != to perform equally
well, instead
