# ITK 5.0 Alpha 1: Modern C++

**URL:** https://discourse.itk.org/t/itk-5-0-alpha-1-modern-c/843
**Category:** Announcements
**Tags:** c-plus-plus-11, release, itk-releases
**Created:** [April 17, 2018, 9:04pm UTC](https://discourse.itk.org/t/itk-5-0-alpha-1-modern-c/843 "2018-04-17T21:04:26Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [April 30, 2018, 10:40am UTC](https://discourse.itk.org/t/itk-5-0-alpha-1-modern-c/843/6 "2018-04-30T10:40:15Z")

</div>

> [@lassoan](#):
>
> Do you have some numbers on performance improvement? Which parts of ITK got faster and by how much?

It appears that the current ITK master branch is in some cases \> 40 x faster _**(yes, more than forty times!)**_ than 4.13. 🤩 At least, that’s what I observed, doing `HoughTransform2DCirclesImageFilter::Update()`, compiled with MSVC 2015 64-bit Release. The source of my little test is at item 4 of the topic [Removal of `virtual` keywords from ConstNeighborhoodIterator - #4 by blowekamp](https://discourse.itk.org/t/removal-of-virtual-keywords-from-constneighborhooditerator/814/4)

The specific `filter->Update()` call in that test takes me more than 10 minutes when using ITK 4.13, and _less than 15 seconds_ when using the ITK master branch!!! As I observed with commit [Merge topic 'Remove-virtual-NeighborhoodAccessorFunctor-destructor' · Kitware/ITK@fa68b53 · GitHub](https://github.com/Kitware/ITK/commit/fa68b5365071b3e07f3861c836d3fd93935471d5).

This performance gain was achieved by a number of independent improvements, including:

- A rigorous code cleanup of `GaussianDerivativeImageFunction`, especially

> <https://github.com/Kitware/ITK/commit/3c5a935f758d6964c0bcba388aa2acdcd1ebdcc6>
>
> Removed Gaussian blurring from GaussianDerivativeImageFunction::EvaluateAtIndex
> …as the blurring usually took a lot of time (possibly 50 % or more), whereas its
> result, as stored in 'value', would be multiplied by 'centerval', which would
> always be zero.
> 
> It appears a bug that the blurring had zero effect, and this bug appeared to
> be there already with the very first commit, 2003-05-29, SHA-1:
> 27973617ab1b7164ae98407bd3aefffa62c18ab0 (when the code was still located at
> Code/Common/itkGaussianDerivativeImageFunction.txx).
> 
> Removed creation of Gaussian blurring kernel from RecomputeGaussianKernel(),
> as it is no longer used by now. Also removed GaussianFunctionType,
> GaussianFunctionPointer, RecomputeContinuousGaussianKernel(const double \*),
> m\_ContinuousOperatorArray, m\_GaussianFunction, as they were not used (anymore).
> 
> Note: A more effective blurring is still to be implemented, to be added to
> a future version of ITK.
> 
> See also the discussion at
> https://discourse.itk.org/t/hough-transform-2d-circles-image-filter-getcircles-patch/350/39
> 
> Change-Id: I51b0976c67d5be320c009b31d98e6f3f014fc1af

- Reducing the number of memory allocation during neighborhood operations, for example:

> <https://github.com/Kitware/ITK/commit/ae249c9963b87ae065a00d7ddf3cf96c4c69e2ae>
>
> \* Replaced for-loops by std::copy calls.
> \* Removed redundant m\_ElementCount ass…ignments.
> \* Avoided reallocation in set\_size when size does not change.
> 
> Change-Id: I50bca9756989def871266e280616f876dc111c1e

- Removing virtual function calls during neighborhood iteration:

> <https://github.com/Kitware/ITK/commit/111486494fe770d8907eec347fa1e624b10fce3c>
>
> Replace virtual specifiers in NeighborhoodIterators with
> ITK\_ITERATOR\_VIRTUAL ma…cro defined to "".
> 
> Virtual table lookup appeared to cause a significant performance
> penalty. ConstNeighborhoodIterator member functions are often called
> with a high frequency, for example within the inner loop of an image
> filter update, so removing the 'virtual' keywords here can yield a
> significant performance gain.
> 
> Co-authored-by: Niels Dekker \<N.Dekker@lumc.nl\>
> 
> Change-Id: If2d4a4cbc7c4ff9cffd3af84b2621fe9e4be583c

- Introduction of a new `ShapedImageNeighborhoodRange` class

> <https://github.com/Kitware/ITK/commit/fd8b105a2fb0f51eb993145fb02db91226607789>
>
> ShapedImageNeighborhoodRange allows iteration over a neighborhood of
> pixels, ver…y much like NeighborhoodIterator and ShapedNeighborhoodIterator.
> But it has a new design and a new interface, offering iterators similar to
> those from the C++ Standard Library.
> 
> New features:
> \* Can be used in C++11 range-based for loops
> \* Can be used to easily construct std containers (e.g., std::vector)
> \* Can be passed directly to std algorithms (std::for\_each, std::copy, etc.)
> \* Can also be used with std C++ \<numeric\>, e.g., std::inner\_product
> \* Supports bidirectional iteration (both ++it and --it)
> 
> Performance related properties:
> \* No dynamic memory allocation (not even during construction)
> \* No virtual functions (even its destructors are non-virtual)
> \* No 'mutable' data members, making it easier to write thread-safe code.
> \* All member functions 'noexcept', each class 'final'.
> 
> Adapted GaussianDerivativeImageFunction to use the new
> ShapedImageNeighborhoodRange + range-based for loop, instead of
> ConstNeighborhoodIterator + NeighborhoodInnerProduct, to calculate the
> inner product. A significant performance improvement was observed
> (reduction of run-time duration with more than 25%). Documented that
> GaussianDerivativeImageFunction is now thread-safe.
> 
> Change-Id: I39115c957b997277c0d5c9b48903284a87254d0d

Hope that helps, Niels

---

_[View the full topic](https://discourse.itk.org/t/itk-5-0-alpha-1-modern-c/843)._