code profiling: constantDensitySampling()

[dylanbeaudette]

There is likely room for improvement in constantDensitySampling():

• implement parallel processing of sample.by.poly() as applied to an sp object to be sampled
• more efficient use of try() / if() within sample.by.poly()

Profiling data for constantDensitySampling(), see documentation:

Some recent stats:

• Drummer series extent (1,481,412 ac.) @ 0.01 pts / ac. = 13 seconds
• San Joaquin series extent (457,649ac.) @ 0.01 pts / ac. = 0.9 seconds
• Auburn series extent (36,5341 ac.) @ 0.01 pts / ac. = 0.6 seconds

[dylanbeaudette]

There is only limited support for sampling st objects, see the porting wiki. Currently, only "random" sampling of st objects is supported, and it is about as efficient as sp::spsample().

Eventually, we will want to migrate over to sf because of the spatial indexing.

[dylanbeaudette]

Experiments with parallel processing on Windows (parallel package: parLapplyLB()) suggest that the underlying functions are mostly tied-up with disk IO, especially when polygons are large. There isn't likely to be much of an improvement unless:

• I am doing it incorrectly
• there are many, many polygons to sample (n.polygons > n.cores)
• sampling a single polygon is fast relative to total required sampling time
• further efficiency can be made in sample.by.poly

Worth the effort? Not sure. I'll commit these changes and test further.

Here is some great discussion on when / where / how parallelization might be possible in Windows. More details here.

There is a lot of overhead when using parallel on Windows:

[dylanbeaudette]

Strange: constantDensitySampling(parallel=TRUE) is 2x slower than serial processing, unless the function code is sourced into the current R session. How could this be?

[dylanbeaudette]

I don't think that parallel processing is working as intended, even for a very large number of samples. Consider alternatives to sp::spsample.