PERF: Optimize SarSensor Module

Summary

Improvement of the performances of SarSensorModel (search for 0 doppler, position interpolation, slant range to ground range conversion...)

Rationale

This MR supersedes and closes !934 (closed)

In continuation of !933 (merged), and the profiling of https://gitlab.orfeo-toolbox.org/s1-tiling/normlim_sigma0 XYZToImage and of SARDEMProjection fork (initially from DiapOTB) applications, several hotspots have been found.

Profiling has been done on the execution of SARDEMProjection on a S1 Image, to produce all the data the application can produce.

Here is the situation before optimization:

And here is what is observed after optimization:

We can see more than x2 on the performances of SARDEMProjection filter.

Implementation Details

SarSensor interface and internal functions have been sanitized

• It's now possible to request only the azimuth time of the current point without triggering position interpolation
• ECEF coordinates of the current point aren't computed at every function call
• Return by value is favoured over C-like output parameters interface -- yet the legacy interface hasn't been removed
• As a finer (and alternative) interface is provided, we can compute on top of previous results without computing then all again (azimuth time, sensor position...)
  • Internally we remember the 2 OrbitStateVector samples that surround the azimuth time of the doppler 0 found; they are immediately reused when we wish to extrapolate the position and velocity at that time.

The Lagrangian interpolation of sensor position and velocity caches invariant data

• Given the reference orbit, we precompute and cache all the possible inverse of products of t[i] - t[j] that were computed on the fly every time. This may alter final precision.

• For a given time, we also cache all the t[j] - azimuthTime.

SarSensorModel::ApplyCoordinateConversion: Remove unnecessary allocations, dichotomic search

• ApplyCoordinateConversion was systematically copying or filling a new vector every time it was called. These dynamic allocations are not necessary. Polynomials are now evaluated on the fly without storing intermediary coefficients. This may alter final precision.

• Record samples were searched in a linear fashion every time instead of doing it by dichotomy.

Other micro-optimizations:

• Avoid pow(sqrt(v), 2)...
• Factorize out constant floatting point expressions. Indeed C++ standard required floatting points expressions to be resolved from left to right in strict mode. This prevents factorizing out 2/C in 2. * range / C. Two multiplications and one division will be done at every call instead of a single multiplication. This is likely to alter final precision.

Future optimization ideas

See !934 (closed)

searchLagrangianNeighbourhood: Search the OrbitStateVector sample by dichotomy

As this function didn't appear in my use case, it didn't appear as an hotspot. The search for the closest sample should be done by dichotomy.

EcefToWorld(): Compute final atan2 on best candidate only

EcefToWorld() is computing atan2() on every possible solution. This function is quite costly. In the end (on small test), it was more time consuming than accessing DEM data (XYZToImage application)

Inline functions from otbDateTime

Ratio() and NumberOfTicks() are extremely short functions that were called a lot. They can benefit from inlining.

Copyright

The copyright owner is CNES and has signed the ORFEO ToolBox Contributor License Agreement.

---

Check before merging:

• All discussions are resolved
• At least 2 👍 votes from core developers, no 👎 vote.
• The feature branch is (reasonably) up-to-date with the base branch
• Dashboard is green
• Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
• Optionally, run git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i on latest changes and commit