Suggestion: Benchmarks

[mehrdadfeller]

Just a suggestion and not an issue, but I think it would be valuable to the developers if there are some performance benchmarks included. I believe you did some benchmarking at some point but I don't think it was published.

[zytegalaxy]

I love Devin's take on this question:

https://deepwiki.com/search/what-would-be-the-performance_6d4d31f8-8726-49f7-930c-439529554664

[sassanh]

As Devin has wonderfully detected it and mentioned in its answer, I tried to write benchmarks as tests: https://github.com/sassanh/python-redux/blob/main/tests/test_performance.py

I will try to make them more visible by mentioning the outcome in README.md

[sassanh]

Regarding its suggestions, I try to comment on them one by one:

Performance Bottlenecks Analysis

1. Sequential Action Processing: At the moment I think it doesn't justify the complexity it brings, at the moment the core of the store has a very simple single-threaded logic, it runs side-effects and autoruns in other threads with the assumption that those are time consuming stuff and the reducers are very cheap to run. I think with well-implemented reducers, it shouldn't become a bottleneck in the future.
2. Listener Notification Overhead: It's a good idea to run listeners using a thread pool.
3. Event Handler Queue Bottleneck: I think the queue data-structure is optimized for this exact purpose of queueing tasks/messages for worker threads.
4. Memory Allocation for Immutable State: The information should be buffered somewhere and dispatched, and this process needs memory by its nature. I think it can't be changed in an action-dispatching store.

Data-transfer bandwidth considerations:

1. State Serialization: It is not something happening all the time in runtime, it only happens in tests and when writing to filesystem, etc. It doesn't matter, in ubo we have a serialization mechanism for serializing/deserializing data to/from gRPC, it is done by betterproto and it's a repository with good reputation.
2. Event payload size: We have zero problem with this, the only limit here is the bandwidth of the underlying communication infrastructure. Note for ubo: gRPC is binary serialization and is super optimized for this purpose.
3. Worker thread communication: It's in memory, I don't think we have any concern here.