Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
otb
otb
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 273
    • Issues 273
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Main Repositories
  • otbotb
  • Issues
  • #1666

Closed
Open
Opened Jul 06, 2018 by Laurențiu Nicola@lnicolaDeveloper

PERF: Small radius optimization for interpolators

Right now, the interpolators use a variable-length vector to store the coefficients, e.g. https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/blob/develop/Modules/Core/Interpolation/include/otbBCOInterpolateImageFunction.hxx#L84 where CoefContainerType is vnl_vector. This results in a couple of memory allocations for each output pixel.

In practice, most kernels are probably rather small, so it might be worth avoiding the allocations for small radii, like mentioned here: https://groups.google.com/d/topic/otb-developers/6PzpGxkkOhs/discussion.

At the time I abandoned the patch because there was no "small vector" container available (variable-length container which can switch from stack to heap allocation if more space is required). Boost had one, but it wasn't available in the versions supported by OTB. There's also alloca, but that's pretty bad (and discouraged).

I don't think anything has changed, but it's worth keeping this possible optimization in mind. One possible compromise would be to use Boost.SmallVector when we are compiling with a version of Boost that's new enough (it was added in 2015).

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: orfeotoolbox/otb#1666