perf(ivy): improve styling performance

[mhevery]

change the existing implementation from using

string.split(/\s+/);

to a char scan which performers the same thing.

The reason why split(/\s+/) is slow is that:

• /\s+/ allocates new RegExp every time this code executes.
• RegExp scans are a lot more expensive because they are more powerful.

[gkalpak]

Wow, I am quite surprised the VM does not optimize the RegExp literal and creates a new RegExp each time. Are you saying that const re = /\s+/; ... newValues.split(re) makes a difference in performance?

Also, ooc, have you tried / +/ (instead of /\s+/)?

[mhevery]

Wow, I am quite surprised the VM does not optimize the RegExp literal and creates a new RegExp each time. Are you saying that const re = /\s+/; ... newValues.split(re) makes a difference in performance?

1. RegExp have internal state so you can't share them.
2. I think the issue is not that we are allocating RegExp but rather that RegExp is smart, and hence it is not as fast on simples cases as hand tuned. code.

[pkozlowski-opensource]

I've run benchmarks on this PR and here are the results. Before:

  [class]=" '1' ": 291.984 us(-43%)
  [class]=" '1 2' ": 428.390 us(-109%)
  [class]=" '1 2 3 4 5 6 7 8 9 0' ": 1698.592 us(-729%)
  class="A B" [class]=" '1' ": 329.344 us(-61%)
  class="A B" [class]=" '1 2 3 4 5 6 7 8 9 0' ": 1998.899 us(-876%)
  class="A B" [class]=" '1' " [class.foo]="exp": 389.557 us(-90%)
  class="A B" [class]=" '1 2 3 4 5 6 7 8 9 0' " [class.foo]="exp": 2088.971 us(-920%)
  [element.class]="exp": 204.865 us(0%)

After:

  [class]=" '1' ": 264.108 us(-29%)
  [class]=" '1 2' ": 399.907 us(-95%)
  [class]=" '1 2 3 4 5 6 7 8 9 0' ": 1674.186 us(-717%)
  class="A B" [class]=" '1' ": 299.102 us(-46%)
  class="A B" [class]=" '1 2 3 4 5 6 7 8 9 0' ": 1944.948 us(-849%)
  class="A B" [class]=" '1' " [class.foo]="exp": 354.644 us(-73%)
  class="A B" [class]=" '1 2 3 4 5 6 7 8 9 0' " [class.foo]="exp": 2003.856 us(-878%)
  [element.class]="exp": 204.905 us(0%)

so there is a clear improvement here (although I was expecting it to be higher, TBH). Those numbers are confirmed by checking the results under profiler. Before:

After:

One can see that split disappeared but splitOnWhitespace isn't "free". Sadly, the need for split is at the very hart of the algorithm so I'm not sure we can do much about it.

[pkozlowski-opensource]

LGTM. I think we should merge it.
@mhevery I will let you decide on if the perf improvement to the additional code makes it worthwhile.

All concerns addressed.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}