From mtmorgan at fhcrc.org  Sun Nov  4 21:29:00 2012
From: mtmorgan at fhcrc.org (Martin Morgan)
Date: Sun, 04 Nov 2012 12:29:00 -0800
Subject: [Rd] parallel::mclapply list coercion limits opportunities for code
	re-use?
Message-ID: <5096D00C.2020101@fhcrc.org>

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.

   https://stat.ethz.ch/pipermail/r-devel/2012-October/065097.html

Martin
-- 
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...
Name: mclapply.diff
Type: text/x-patch
Size: 1924 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20121104/8c735cb6/attachment.bin>


[Rd] parallel::mclapply list coercion limits opportunities for code re-use?
Martin Morgan