Difference between revisions of "Profiling"

From OTBWiki
Jump to: navigation, search
(A few more tips from my analyses)
(Pixel values: -> link to mode complete study ; note of self-assignment test)
Line 22: Line 22:
  
 
Calling ''static_cast<>'' on pixels is not recommended either as this may induce a converting-construction. Prefer the ''new'' ''itk::CastInto<>'' or ''it::MoveInto<>'' functions which will be proposed as a patch.
 
Calling ''static_cast<>'' on pixels is not recommended either as this may induce a converting-construction. Prefer the ''new'' ''itk::CastInto<>'' or ''it::MoveInto<>'' functions which will be proposed as a patch.
 +
 +
A more thorough analysis will be conducted [OptimizingVectorImageProcessing here].
 +
 +
=== Copy and Assignments ===
 +
 +
When trying to decide how a copy-constructor and how copy-assignment shall be handled, the first step is to decide whether the class really needs to support duplication. Most of the time, the answer is ''NO''. That's why many ITK and OTB classes have their copy-constructor and copy-assignment operator declared private and not implemented.
 +
 +
It's also possible to inherit from classes like ''boost::noncopyable'', or to use C++11 "= delete" annotation.
 +
 +
However, sometimes we have to define new classes that have value semantics. These classes need to support copy-construction and copy-assignment. Almost two decades ago, it was trendy to check for self-assignment -- and to leave the code in a non-exception safe state. Since then, we have learned how to have our code robust to exceptions. It happens such codes do also resist to self-assignment. This means that in the end, a '''correct''' code will resist to self-assignment, and the self-assignment test will optimize the case where we write (directly or indirectly) ''a = a;'', and slightly degrade all other cases.
 +
 +
As the ''a = a;'' case is more than unlikely to appear in usual programs, instead of optimizing it at the expense of all other cases, let's instead '''NEVER test for self assignment'''.

Revision as of 16:30, 26 May 2015

This page compiles some profiling conclusions and tips:

Method GetSize()

  • Avoid:

for (int i=0;i<v.GetSize();++i) {}

  • Prefer:

const unsigned int size = v.GetSize(); for (unsigned int i=0;i<size;++i) {}

Defensive Programming

  • Avoid defensive programming in function called many times. i.e. avoid testing for programming errors. In particular never use std::vector<>::at()
  • Prefer narrow contracts, and test for possible runtime errors before calling functions that have contracts. For more information, see these posts (in French).

Pixel values

Pixel values from otb::VectorImage are actually dynamic vectors. As such avoid to create, copy et destroy pixel values. Instead prefer to minimize the number of pixel objects created (e.g. try to stick to only one instance declared outside a loop), and then assign them new values.

This is also true for generic algorithms that may work on scalar as well as vector pixels.

Calling static_cast<> on pixels is not recommended either as this may induce a converting-construction. Prefer the new itk::CastInto<> or it::MoveInto<> functions which will be proposed as a patch.

A more thorough analysis will be conducted [OptimizingVectorImageProcessing here].

Copy and Assignments

When trying to decide how a copy-constructor and how copy-assignment shall be handled, the first step is to decide whether the class really needs to support duplication. Most of the time, the answer is NO. That's why many ITK and OTB classes have their copy-constructor and copy-assignment operator declared private and not implemented.

It's also possible to inherit from classes like boost::noncopyable, or to use C++11 "= delete" annotation.

However, sometimes we have to define new classes that have value semantics. These classes need to support copy-construction and copy-assignment. Almost two decades ago, it was trendy to check for self-assignment -- and to leave the code in a non-exception safe state. Since then, we have learned how to have our code robust to exceptions. It happens such codes do also resist to self-assignment. This means that in the end, a correct code will resist to self-assignment, and the self-assignment test will optimize the case where we write (directly or indirectly) a = a;, and slightly degrade all other cases.

As the a = a; case is more than unlikely to appear in usual programs, instead of optimizing it at the expense of all other cases, let's instead NEVER test for self assignment.