@@ -532,7 +532,7 @@ def broadcast_axis_partitions(
532
532
then the number of splits is preserved.
533
533
apply_indices : list of ints, default: None
534
534
Indices of `axis ^ 1` to apply function over.
535
- send_all_right: bool, default: True
535
+ send_all_right : bool, default: True
536
536
Whether or not to pass all right axis partitions to each of the left axis partitions.
537
537
enumerate_partitions : bool, default: False
538
538
Whether or not to pass partition index into `apply_func`.
@@ -662,8 +662,7 @@ def broadcast_apply(
662
662
right ,
663
663
):
664
664
"""
665
- Broadcast the `right` partitions to `left` and apply `apply_func` function
666
- using different approaches to achieve the best performance.
665
+ Broadcast the `right` partitions to `left` and apply `apply_func` function using different approaches to achieve the best performance.
667
666
668
667
Parameters
669
668
----------
@@ -681,12 +680,9 @@ def broadcast_apply(
681
680
np.ndarray
682
681
NumPy array of result partition objects.
683
682
"""
684
- # The condition for the execution of `broadcast_apply` is different from
685
- # the same condition in the `map_partitions`, since the columnar partitioning approach
686
- # cannot be implemented for the `apply`. This is due to the fact that different
687
- # partitions of the left and right dataframes are possible for the `apply`,
688
- # as a result of which it is necessary to merge partitions on both axes at once,
689
- # which leads to large slowdowns.
683
+ # The `broadcast_apply` runtime condition differs from
684
+ # the same condition in `map_partitions` because the columnar
685
+ # approach for `broadcast_apply` results in a slowdown.
690
686
if np .prod (left .shape ) <= 1.5 * CpuCount .get ():
691
687
# block-wise broadcast
692
688
new_partitions = cls .base_broadcast_apply (
0 commit comments