MCE began life as a chunking engine with support for serialized output or action; e.g. serializing log data to a single file and not worry about many workers writing simultaneously; e.g. MCE->print($LOG_FH, "$msg\n");
The native grep function will typically run faster for small code. Below, mce_grep has low overhead due to chunking input. Output order is also preserved (not shown).
# $N = 1e6; TGrep......: Took 30.264018774 seconds (4 workers) mce_grep...: Took 0.299300909 seconds (4 workers) native grep: Took 0.106141806 seconds
One reason for using MCE is wanting the freezing and thawing of data done automatically between the manager process and workers or vice versa. Another likely reason is running MCE with AnyEvent or Mojo and benefitting from chunking; e.g. each worker receives 300 hosts or URLs at a time and processing the chunk with desired event loop.
MCE::Queue is not necessary when threads is desired. One can still use Thread::Queue unless wanting priority queues possible with MCE::Queue. Perhaps, Perl is not built with threads support (common on some platforms). Both MCE::Queue and MCE::Mutex support threads and processes.
The next update will include Tutorial.pod demonstrating parallelism for various CPAN modules.
In reply to Re: Wanting some clarification / opinions on MCE vs Threads
by marioroy
in thread Wanting some clarification / opinions on MCE vs Threads
by jmmitc06
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |