Skip to content

Optimizations ideas

Daniele Romagnoli edited this page Aug 6, 2015 · 2 revisions

Avoid un-necessary overhead

Some operations end up being called with a ROI and a NoData range that are completely useless:

  • The ROI is full (equivalent to no ROI)
  • The NoData does not intersect the valid range of values for the current Raster (e.g., nodata is less than 0, with a bytebuffer of type unsigned)

We should be able to recognize these situations, and avoid nodata/ROI processing in these cases

Align nodata with data

It happens that we get a NoData range in double type, but the data is in some other data type, making us hit the slow contains operations. Align the NoData to the data first (this might result in figuring out the NoData is fully out of rnage, see above).

Mark tiles as nodata free

Even when working with nodata, we can have tiles that have none inside, or that are fully within the ROI, it would be nice to mark them as such to avoid extra work in the subsequent operations (we know if nodata or out of ROI has been hit while computing the tile). Idea: Raster wrapper/subclass carrying around those info?