[vtk-developers] vtkDataArrayTemplate

Benjamin Schindler bschindler at student.ethz.ch
Mon Nov 24 10:09:52 EST 2008


Hi John

Thanks for the reply. I've got a few comments because there still are 
some issues with this

- One performance bottleneck is the vtkPointLocator. It can't use the 
GetPointer method because it operates on vtkPoints which wraps around 
arrays and it doesn't seem to offer that interface. Why is there a 
vtkPoints interface anyway (Roughly 50% of the time spent in 
GetClosestNPoints goes to GetPoint and because of this, the code isn't 
even race free)
- Any GetPoint Method currently wraps around GetTuple. And they're used 
really all over the place
- GetPointer is not component sensitive - so retreiving tuple i results 
in arr->GetPointer(i*arr->GetNumberOfComponents()). An tuple-sensitive 
arr[i] operator would be a lot nicer no?

Cheers
Benjamin

John Biddiscombe wrote:
> Benjamin
>
> The GetTuple interface is only intended if you really don't know what 
> type of data you are expecting. You should use the GetPointer cast to 
> float/double etc - this gives you raw access to the array in native 
> form. Only use the GetTuple in emergencies.
>
> vtkDataArrayTemplate is already remplated over types for the bulk of 
> work in creating the class definitions for each type. You should look 
> at some of the imageing filters for examples of how to get a scalar 
> pointer then execute on whatever type you need.
>
> I'm keeping this reply brief as timeis too short. Hopefully someone 
> else will give you further details if you need them.
>
> JB
>> Hi
>>
>> I noticed that my code ran very slow so I did some profiling and I 
>> noticed to my horror, that about 50% of all time is spent inside the 
>> GetTuple (and it's wrappers). Looking at the code I noticed that for 
>> every access a copy of a tuple is generated which is pretty insane 
>> when all you want is a distance to another point...
>> I do realize that in vtk, you never know whether you work with floats 
>> or doubles or ints etc, but I'm sure there are other ways that are 
>> not this hard on performance
>>
>> Are there plans on improving this? I've looked at a few ideas and my 
>> interest was caught by Eigen2, a very fast Math Library making 
>> extensive use of templates challenging even the mkl in terms of 
>> speed. They make heavy use of template expressions so there are no 
>> intermediate copies at any point. I'd guess something like this would 
>> be very much doable for vtk
>>
>> Even though it would be quite some work, I imagine all of vtk would 
>> gain significantly from this - in terms of genericity, design and 
>> performance
>>
>> Any comments?
>>
>> Cheers
>> Benjamin
>> _______________________________________________
>> vtk-developers mailing list
>> vtk-developers at vtk.org
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>




More information about the vtk-developers mailing list