mirai_map
much slower than its synchronous sequential and parallel::parLapply
'alternatives'
#276
Replies: 3 comments
-
I'm afraid it's difficult for me to comment given all the packages involved. In particular I can't really speak to 'openxlsx'. If you want me to look at mirai performance, then ideally it would be something just involving mirai. I'm also happy to look at things in a Shiny context, but then it becomes more difficult to narrow down. |
Beta Was this translation helpful? Give feedback.
-
This may be a case of #300 where you are accidentally shipping large objects to the parallel workers. Please take care when you are passing environments or functions. |
Beta Was this translation helpful? Give feedback.
-
I have no way to reproduce this, so am closing for now. If you have a more minimal example, and still run into this issue, please feel free to open another discussion/issue. Thanks. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm still struggling to use
mirai_map
to run a piece of code (that takes quite a long time to complete) in an asynchronous parallel way within a Shiny app.In this context I was looking for benchmarks in the synchronous world and was quite surprised to see that in this specific example
mirai_map
completed on my computer (with 8 logical cores) in approx. 01:41 while the sequential andparallel::parLapply
synchronous 'alternatives' completed in 01:01 and 00:22, respectively.Why is there such a big difference between
mirai_map
andparallel::parLapply
?Below are the three pieces of code:
parallel::parLapply
mirai_map
Beta Was this translation helpful? Give feedback.
All reactions