refactor(rust): Use defunctionalization in polars-core scalar.rs in order to reduce code duplication

[burakemir]

This change reduces the number of copies of the bitonic_map function from 144 to 12. It should help with build times and code size, without any change in performance.

[codecov]

Codecov Report

Attention: Patch coverage is 92.68293% with 3 lines in your changes missing coverage. Please review.

Project coverage is 79.10%. Comparing base (db1684d) to head (d21f75d).

Files with missing lines	Patch %	Lines
...polars-core/src/chunked_array/comparison/scalar.rs	92.68%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #20377   +/-   ##
=======================================
  Coverage   79.10%   79.10%           
=======================================
  Files        1572     1572           
  Lines      219958   219963    +5     
  Branches     2465     2465           
=======================================
+ Hits       173991   174006   +15     
+ Misses      45399    45389   -10     
  Partials      568      568           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orlp]

While better compile times are good, and it probably doesn't matter since it's only called a logarithmic number of times it still feels bad to me we do a match on every single comparison now.

[burakemir]

The apply method should in theory be inlined and the match disappear.

I have an alternative approach that uses a custom closure type that achieves the same reduction, would you prefer a PR for that instead?
branch: https://github.com/burakemir/polars/tree/scalar_customclosure
convenient link to scalar.rs (only file that changes, like in this PR): https://github.com/burakemir/polars/blob/scalar_customclosure/crates/polars-core/src/chunked_array/comparison/scalar.rs

[orlp]

@burakemir If it were inlined it would not reduce the amount of code generated after all, no?

[burakemir]

The problem addressed is the needless duplication because of monorphization: the FA and FD generic parameters get instantiated with a special (per-call site) closure type. This leads to the 144 copies of bitonic_mask, which is reduced to 12 by either this or the alternative approach.

You are of course correct that inlining can in general inlining will cause code size increases. In case of the match statement with a statically known scrutinee, the whole match statement should be removed, which then ideally gives rise to further inlining of the actual comparison method (though I have not checked).