Pauan / rust-signals

Zero-cost functional reactive Signals for Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question - Do the native Mutex, RwLock used affect performance ?

szagi3891 opened this issue · comments

I noticed that native mutexes were used for state synchronisation
use std::sync::{Arc, Weak, Mutex, RwLock }

Doesn't this affect performance ?
Wouldn't it be better to use a mutex from tokio ?

commented

You mean parking_lot? This crate is designed to be portable, it can work on any platform (including Wasm). There are various issues with parking_lot that make it not feasible right now. At least on Wasm, the stdlib Mutexes are much faster.

There have been substantial efforts in integrating parking_lot into the stdlib:

rust-lang/rust#56410
rust-lang/rust#93740

Most of the performance improvements seem to have already been merged, so I'm curious whether parking_lot is actually faster or not.

You mean parking_lot? This crate is designed to be portable, it can work on any platform (including Wasm). There are various issues with parking_lot that make it not feasible right now. At least on Wasm, the stdlib Mutexes are much faster.

There have been substantial efforts in integrating parking_lot into the stdlib:

rust-lang/rust#56410 rust-lang/rust#93740

Most of the performance improvements seem to have already been merged, so I'm curious whether parking_lot is actually faster or not.

I don't know whether the std mutex is faster than parking_lot either. I came from here when I decided to use spin at first. And now I think the std mutex and parking_lot would be better for most synchronization cases.

But between std mutex and parking_lot, I think std mutex should be preferred at first unless you have an extremely time-efficiency sensitive case.

While I do remember parking_lot speeds up my toy nbody simulation a lot 5 years ago, on modern CPUs (I tested apple M1, Zen3+), I really see no performance gain from parking_lot (or even worse, parking_lot has a large negative performance impact).

While I do remember parking_lot speeds up my toy nbody simulation a lot 5 years ago, on modern CPUs (I tested apple M1, Zen3+), I really see no performance gain from parking_lot (or even worse, parking_lot has a large negative performance impact).

Things may change a lot in the past 5 years. I do think that trying the built-in one is a good practice at first.