Skip to content

Minimize amount of weak vtables

When building vtkm with Wweak-vtableswe get warnings about duplicate vtkm virtual classes having multiple vtables. If a class has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit, causing a significant increase in compile/link time and an increase in both final output size, but also runtime load time[1][2][3].

Currently vtkm has weak vtables being generated for the following classes:

  • vtkm::cont::ArrayHandle
  • vtkm::cont::CellSet
  • vtkm::cont::CoordinateSystem
  • vtkm::cont::detail::PolymorphicArrayHandleContainerBase
  • vtkm::cont::DynamicCellSetBase
  • vtkm::cont::Field
  • vtkm::cont::ArrayHandleExecutionManagerBase
  • vtkm::cont::internal::SimplePolymorphicContainer.h

It looks like the majority of these class can easily move to have a compilation unit or removing unneeded virtual markup ( DynamicCellSetBase ). The challenges are in vtkm::cont::ArrayHandle and vtkm::cont::CellSet.

The vtkm::cont::ArrayHandle only looks to have a virtual destructor, and the VTK_M_ARRAY_HANDLE_SUBCLASS_IMPL seems to define an empty virtual destructor so it looks like we can fully remove this ( @kmorel do you agree? )

The vtkm::cont::CellSet seems to really require some form of polymorphic behavior as all the GetNumberOf methods require polymorphism. Our options include investigating if CRTP can solve the problem. Another option is looking into having a compilation unit for 'common' instances of CellSetExplicit, and CellSetSingleType. Lastly we can just accept having an overhead for CellSet, but I am concerned that once vtk-m is used in lots of compilation units this will become untenable.

[1]http://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers [2]http://allievi.sssup.it/techblog/archives/791 [3]vtable is only emitted in the translation unit where the key method is defined.