> ... with assignments inside of loops like this:
>
> reweight = function(iter, w, Q) {
> for (i in 1:iter) {
> wT = w * Q
> }
> }
> ... before the RHS is executed, the LHS allocation would be added
> to a small fixed length list of available space which is checked
> before future allocations. If the same size is requested before the
> next garbage collection, the allocation is short-circuited and the
> allocation is reused. This list could be very small, possibly even
> only a single entry. Entries would only be put on the list if they
> have no other references.
Reusing the LHS storage immediately isn't possible in general, because
evaluation of the RHS might produce an error, in which case the LHS
variable is supposed to be unchanged. Detecting special cases where
there is guaranteed to be no error, or at least no error after the
first modification to newly allocated memory, might be too
complicated.
Putting the LHS storage on a small free list for later reuse (only
after the old value of the variable will definitely be replaced) seems
more promising (then one would need only two copies for examples such
as above, with them being used in alternate iterations). However,
there's a danger of getting carried away and essentially rewriting
malloc. To avoid this, one might try just calling "free" on the
no-longer-needed object, letting "malloc" then figure out when it can
be re-used. Unfortunately, that seems not to be safe, because it's
posslble that there is a reference to the no-longer-needed object on
the PROTECT stack, even though no one should actually be looking at
it any more.
In the current version of pqR (see pqR-project.org), modifications are
(often) done in place for statements such as w = w * Q, but not
curretly when the LHS variable does not appear on the RHS.
Regards,
Radford Neal
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
