[Rd] parallel::mclapply list coercion limits opportunities for code re-use?
mtmorgan at fhcrc.org
Sun Nov 4 21:29:00 CET 2012
The attached diff address the following issues in mclapply
mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be
an efficient representation and is not required if the object implements length,
[, and [[ methods (lapply must also work on the object, either through coercion
to a list at the 'inner.do' level or through other means, e.g., promoting lapply
to a generic and writing a method specialized for the object). As written
someone wishing to implement mclapply on an object not efficiently represented
as a list would need to promote mclapply to a generic, and then re-implement an
mclapply method for their object, rather than re-using the existing code.
mcparallel is not consistently invoked with a 'name' argument; a name seems to
be superfluous to the code.
Creating the variable 'schedule' makes a full copy of a potentially large object
in the master process; delaying until required in the inner.do function may (?)
result in less copying.
Avoiding coercion to a list is similar to a suggestion for pvec.
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1924 bytes
Desc: not available
More information about the R-devel