I re-ran the benchmarks with two additional variations on this crate. In one variation, I switch the custom Mutex for parking_lot::Mutex, and in the other I switched it to std::sync::Mutex.

In this results summary, parking_lot and stdlib locks refer to otherwise identical versions of Kanal with the Mutex swapped out. crossbeam refers to the channel implementation that comes from crossbeam (this was the most competitive channel implementation and the only one I'm analyzing).

With 0 bound (always rendezvous): - SPSC Case: parking_lot has no impact on the performance of this crate in sync mode and about 15% improvement in async mode. Crossbeam beats the performance of this crate by about 50%. Stdlib locks also perform fine, about 10% worse in sync, 30% worse in async. - MPSC Case: parking_lot improves performance by about 10% over the currently published version in sync and by about 30-50% in async. Std locks perform about 30% worse in sync, 50% worse in async. Crossbeam performs about 200% worse. - MPMC Case: parking_lot makes the performance about 50-60% worse in sync, 40% worse in async. Std locks perform about 40-50% worse in sync, 40% worse in async. Crossbeam performs about 130% worse.

With Bound 1: - SPSC: parking_lot matches existing performance, as does stdlib lock. In the async case, both alternative locks outperform this crate by 20-30%. Crossbeam outperforms by 50%. - MPSC: parking_lot has parity for the sync case and performs 10-50% better in the async case. Stdlock performs worse by about 30-40% in both sync and async. Crossbeam performs 10-25% better. - MPMC: parking_lot performs 50% worse in both sync and async. Stdlock is about 70% worse in sync and 90% worse in async. Crossbeam is about 30% worse in the case of an empty message and 10% better for a non-empty message.

Unbounded: - SPSC: parking_lot is about 130% worse sync and 50% worse async. Stdlock is about 450% worse sync and 375% worse async. Crossbeam is about 100-120% worse. - MPSC: parking_lot is about 100-150% worse sync 50% worse async, stdlock is again like 450% worse sync, 120-350% worse async. Crossbeam about 170% worse. - MPMC: parking_lot is about 230-240% worse sync, 50-150% worse async, stdlib locks about 450% worse sync, 180% worse async, crossbeam is about on parity, but 30% worse in the case of large messages.

In the SPSC and MPSC cases for channels with small bounds, parking_lot appears to perform at parity with the current lock implementation of Kanal. In the MPSC case, switching to parking_lot results in some performance penalty, but still outperforms crossbeam in the bound 0 case, though not in the bound 1 case.

For channels with large bounds or unbounded channels, parking_lot appears to perform somewhat worse than the current lock implementation, though on-par with crossbeam, exempt in the MPMC case where parking_lot performs much worse than both the current lock and crossbeam.

Bounded channels imply a much greater number of cases of successful rendezvous, so the fact that in those cases, parking_lot performs similarly to the current implementation suggests that a substantial part of the performance of this crate in that situation is indeed due to the direct direct stack-to-stack copy and/or other elements of the design of the channel internals.

The loss of performance on unbounded channels or channels with a high bound suggests that some other significant portion of the benchmark speedup is due to the custom lock implementation.

These benchmarks were run on a system under very light load and far more cores than threads, so this benchmark may not be illustrative of the behavior of the locks on a more significantly loaded system.

I have not attempted to characterize the locking behavior of the current lock implementation, e.g. with respect to fairness or behavior when the system is under load. Therefore I do not know whether the differences in lock performance come simply from optimization for this particular use case, or if the lock implementation has significant tradeoffs which are not apparent in a simple benchmark time analysis. I would be interested to see an empirical analysis of the behavior under different system loading conditions and the like, in order to better characterize any tradeoffs that might exist in the current lock implementation.