Replies: 1 comment 1 reply
-
Hey there, Thanks a lot for your interest in the project! You're absolutely right about some cases where using separate threads might not the best choice. In scenarios where there's a significant amount of I/O, especially with large objects, the overhead of serializing data between threads becomes a bottleneck. I'll be releasing a benchmark soon which I hope will give a clear understanding of when this library truly shines and in which cases it might be better to use a single thread instead. In general, you'd want to offload as much of the CPU-bound processing (Hashing passwords, generating randomness etc..) to a separate thread, while preventing having to transfer very big objects. In cases where you want to process a lot of data, it is recommended to let the thread do the data loading instead, with something like |
Beta Was this translation helpful? Give feedback.
-
Hey, amazing project.
One question that I have immediately upon seeing this. Is there any benchmark that proves in what case this library will shine and in which it will not?
AFAIR (without Googling and double checking, so excuse me if I messed that up with something else and this whole text below is a bunch of nonsense) moving data between main thread and workers require inputs and outputs to be serialized back and forth. And in case inputs and outputs are big, serialization overhead may be that big it actually faster to run certain things just in a promise without offloading it anywhere.
As I said before, I may be mistaken, so, apologies if so. But, nonetheless, benchmark that will clearly show how faster this thing is (and in which cases) would be awesome to demonstrate this concept is a viable strategy :)
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions