[vtk-developers] VTK6 performance issue wrt VTK5
Berk Geveci
berk.geveci at kitware.com
Wed May 14 12:35:54 EDT 2014
Hi Julien,
I am happy to hear that it wasn't my code behind the performance issue :-)
I have plans to revise the pipeline passes. The main idea is to reduce the
number of passes by propagating request on the upstream of a pass while
propagating data (or meta-data) during the downstream. Something like:
- RequestInformation
- RequestTime / RequestDynamicMetaData
- RequestUpdateExtent / RequestData
Although the main reason behind this is correctness (the current approach
has a flaw in it), it should improve performance also. Also, it is possible
certain checks are being performed more than necessary so that needs to be
tracked down.
In summary, I would leave things as they are in the short term and live
with the performance problem. Once I am done with my changes, upgrading to
the next version of VTK (which should be painless since there are no
planned API changes) should address the issue.
If this is not an option, we can find a way to short-circuit those time
passes.
Best,
-berk
On Wed, May 14, 2014 at 12:06 PM, Julien Finet <julien.finet at kitware.com>wrote:
> Hi,
>
> I have noticed a decrease in performance when switching from VTK5 to VTK6.
> This is related to the number of actors in the scene and the pipeline
> updates.
>
> Here I use VTK Rendering TimeRenderer test to compare the 2 versions. To
> average the timing, the render loop has been increased from 360 to 3600
> iterations. Here are some results:
> VTK 5: 100 actors: 13.5s
> VTK 6: 100 actors: 13.5s (100%)
> VTK 5: 300 actors: 13.1s
> VTK 6: 300 actors: 15.6s (115%)
> VTK 5: 600 actors: 13.1s
> VTK 6: 600 actors: 21.3s (163%)
> VTK 5: 1000 actors: 15.1s
> VTK 6: 1000 actors: 33.5s (222%)
>
> A simpler test that only calls GetBounds() multiple times on a
> vtkPolyDataMapper produces the following time-ordered-backtraces:
> VTK 5:
> Running Time Self Symbol Name
> 221.5ms 100.0% 0.6 vtkPolyDataMapper::GetBounds()
> 122.0ms 55.0% 0.6 vtkStreamingDemandDrivenPipeline::Update(int)
> 090.0ms 40.6% 0.4 vtkDemandDrivenPipeline::UpdateInformation()
> 019.3ms 8.7% 1.0
> vtkStreamingDemandDrivenPipeline::PropagateUpdateExtent(int)
> 009.6ms 4.3% 1.0 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)
> 001.0ms 0.4% 1.0 vtkExecutive::CheckAlgorithm(char const*,
> vtkInformation*)
> 000.4ms 0.1% 0.0 vtkDemandDrivenPipeline::UpdateData(int)
> 000.2ms 0.0% 0.2 vtkAlgorithm::GetNumberOfOutputPorts()
> 000.2ms 0.0% 0.2 vtkInformationIntegerKey::Set(vtkInformation*, int)
> 000.2ms 0.0% 0.2 vtkInformation::Has(vtkInformationRequestKey*)
> 000.1ms 0.0% 0.1 vtkInformationRequestKey::Has(vtkInformation*)
> 000.1ms 0.0% 0.1 vtkExecutive::GetOutputInformation()
> 000.1ms 0.0% 0.1
> vtkStreamingDemandDrivenPipeline::REQUEST_UPDATE_EXTENT()
> 000.0ms 0.0% 0.0 vtkExecutiveInternals::GetInputInformation(int)
> 000.0ms 0.0% 0.0 vtkDemandDrivenPipeline::UpdateDataObject()
> 000.0ms 0.0% 0.0 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)
> 000.0ms 0.0% 0.0 vtkDemandDrivenPipeline::REQUEST_DATA()
> 064.2ms 28.9% 1.7 vtkPolyDataMapper::Update()
> 027.5ms 12.4% 1.1 vtkPainterPolyDataMapper::ComputeBounds()
> 002.1ms 0.9% 0.0 vtkExecutive::GetNumberOfInputConnections(int)
> 000.8ms 0.3% 0.8 vtkClipPlanesPainter::UpdateBounds(double*)
> 000.7ms 0.3% 0.7 vtkPainter::GetDelegatePainter()
> 000.6ms 0.2% 0.6 vtkDataObject::SetUpdateExtent(int, int, int)
> 000.5ms 0.2% 0.4 vtkPainter::UpdateBounds(double*)
>
> VTK 6:
> Running Time Self Symbol Name
> 1077.5ms 100.0% 2.6 vtkPolyDataMapper::GetBounds()
> 846.6ms 78.5% 0.7 vtkStreamingDemandDrivenPipeline::Update(int)
> 335.7ms 31.1% 2.0 vtkStreamingDemandDrivenPipeline::PropagateTime(int)
> 298.3ms 27.6% 1.3
> vtkStreamingDemandDrivenPipeline::UpdateTimeDependentInformation(int)
> 123.8ms 11.4% 1.4
> vtkStreamingDemandDrivenPipeline::PropagateUpdateExtent(int)
> 068.4ms 6.3% 0.4 vtkDemandDrivenPipeline::UpdateInformation()
> 009.2ms 0.8% 1.6 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)
> 000.6ms 0.0% 0.6 vtkInformationIntegerKey::Set(vtkInformation*, int)
> 000.5ms 0.0% 0.5 vtkExecutive::GetOutputInformation()
> 000.4ms 0.0% 0.4 vtkInformation::Set(vtkInformationRequestKey*)
> 000.4ms 0.0% 0.4 vtkInformationRequestKey::Set(vtkInformation*)
> 000.3ms 0.0% 0.0 vtkDemandDrivenPipeline::UpdateData(int)
> 000.3ms 0.0% 0.3 vtkInformation::Set(vtkInformationIntegerKey*, int)
> 000.3ms 0.0% 0.3 vtkAlgorithm::GetNumberOfOutputPorts()
> 000.2ms 0.0% 0.2 vtkInformation::Has(vtkInformationRequestKey*)
> 000.2ms 0.0% 0.2 vtkExecutiveInternals::GetInputInformation(int)
> 000.1ms 0.0% 0.1 vtkExecutive::CheckAlgorithm(char const*,
> vtkInformation*)
> 000.1ms 0.0% 0.1 vtkDemandDrivenPipeline::UpdateDataObject()
> 000.1ms 0.0% 0.1 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)
> 000.1ms 0.0% 0.1 vtkInformationRequestKey::Has(vtkInformation*)
> 000.0ms 0.0% 0.0 vtkExecutive::GetInputInformation()
> 0080.8ms 7.4% 0.8 vtkDemandDrivenPipeline::UpdateInformation()
> 0048.6ms 4.5% 1.2 vtkPainterPolyDataMapper::ComputeBounds()
> 0030.5ms 2.8% 1.9 vtkStreamingDemandDrivenPipeline::SetUpdateExtent(vtkInformation*,
> int, int, int)
> 0021.7ms 2.0% 0.6 vtkAlgorithm::GetInputAlgorithm(int, int)
> 0010.3ms 0.9% 2.2 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
> vtkInformationVector**, vtkInformationVector*)
> 007.5ms 0.6% 4.1 vtkPainter::UpdateBounds(double*)
> 005.8ms 0.5% 1.2 vtkAlgorithm::GetInputInformation(int, int)
> 005.2ms 0.4% 0.9 vtkAlgorithm::UpdateInformation()
> 002.4ms 0.2% 0.1 vtkExecutive::GetNumberOfInputConnections(int)
>
>
> Calling SetStatic() on all the mappers improve things:
> VTK 5: 100 actors: 6.7s
> VTK 6: 100 actors: 6.7s (100%)
> VTK 5: 1000 actors: 6.7s
> VTK 6: 1000 actors: 8.4s (125%)
> While the performance is still hit, it is more acceptable. However, for my
> use case, making my mappers static is not an option.
>
> A hack to disable the time propagation also improve things a bit:
> VTK 5: 100 actors: 6.7s
> VTK 6: 100 actors: 6.7s (100%)
> VTK 5: 1000 actors: 15.1s
> VTK 6: 1000 actors: 20.0s (132%)
> While time propagation is responsible for a large part of the slowness, it
> still does not explain 100% of the performance decrease.
>
> Any suggestion ?
> As a quick fix, we could improve the "Static" property of the mappers by
> specifying if the mapper input is "time static" (e.g.
> vtkMapper::SetStatic(2) or vtkMapper::SetTimeStatic(1)).
>
> Thanks,
> Julien.
> p.s. TimeRenderer currently segfaults in VTK6 trunk due to a missing
> auto-initialization.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140514/f73bb1b7/attachment-0002.html>
More information about the vtk-developers
mailing list