[vtkusers] vtkPoints.SetPoints bug?

[David Gobbi]

On Sun, Nov 25, 2018 at 1:47 PM David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Eric,
>
> In your benchmarks, most of the time is going to the Python overhead.  So
> I agree with your hypothesis: in Python, InsertPoint() will be faster than
> SetPoint() simply because the InsertPoint() only has 3 parameters while
> SetPoint() has 4. It's all about the time that Python takes to build the
> args tuple (function calls in Python are not cheap).
>

Actually it's probably not just the Python function call overhead.  The
benchmark loop for SetPoint() also contains more operations and creates an
additional variable.

  David


On Sun, Nov 25, 2018 at 1:09 PM Fahlgren, Eric <
> eric.fahlgren at smith-nephew.com> wrote:
>
>> Using InsertPoint alone instead of SetPoint+Modified also pings the
>> modified time, which brings us to an interesting side point.
>>
>>
>>
>> We apparently had avoided InsertPoint due to performance issues in the
>> past, so I benchmarked them and InsertPoint is now about 10% faster than
>> SetPoint (which seems odd, since you’d think InsertPoint would be doing
>> some extra mallocs that are clearly J more expensive than simple
>> indexing).  Maybe the extra data marshalling for the id parameter is the
>> difference?
>>
>>
>>
>> from tools.timethis import timethis
>>
>> import vtk
>>
>>
>>
>> nPts = 5
>>
>> points = vtk.vtkPoints()
>>
>>
>>
>> for iteration in range(21):
>>
>>     print(f'{iteration:3d} {nPts:9_d}')
>>
>>
>>
>>     with timethis('Insert'):
>>
>>         points.SetNumberOfPoints(0)
>>
>>         for i in range(nPts):
>>
>>            x = y = z = float(i)
>>
>>             points.InsertNextPoint(x,   y,   z)
>>
>>             points.InsertNextPoint(x+1, y+2, z+3)
>>
>>
>>
>>     with timethis('Set'):
>>
>>         points.SetNumberOfPoints(nPts * 2)
>>
>>         for i in range(nPts):
>>
>>             id = i*2
>>
>>             x = y = z = float(i)
>>
>>             points.SetPoint(id+0, x,   y,   z)
>>
>>             points.SetPoint(id+1, x+1, y+2, z+3)
>>
>>         points.Modified()
>>
>>
>>
>>     nPts *= 2
>>
>>
>>
>>
>>
>>   0         5
>>
>>   1        10
>>
>>   2        20
>>
>> ...
>>
>> 18 1_310_720
>>
>> 19 2_621_440
>>
>> 20 5_242_880
>>
>> Insert :   0.367240s : N=   21 : stddev=0.89898
>>
>> Set    :   0.417269s : N=   21 : stddev=1.01908
>>
>>
>>
>>
>>
>> *From:* vtkusers [mailto:vtkusers-bounces at public.kitware.com] *On Behalf
>> Of *Fahlgren, Eric
>> *Sent:* Sunday, November 25, 2018 10:01 AM
>> *To:* David Gobbi
>> *Cc:* vtkusers at public.kitware.com
>> *Subject:* Re: [vtkusers] vtkPoints.SetPoints bug?
>>
>>
>>
>> Thanks, David, that fixes it.  I’m pretty surprised at this since the
>> code was actually written back in the 5.2 days and hasn’t been touched
>> since…
>>
>>
>>
>> Eric
>>
>>
>>
>> *From:* David Gobbi [mailto:david.gobbi at gmail.com]
>> *Sent:* Sunday, November 25, 2018 8:25 AM
>> *To:* Fahlgren, Eric
>> *Cc:* vtkusers at public.kitware.com
>> *Subject:* Re: [vtkusers] vtkPoints.SetPoints bug?
>>
>>
>>
>> Hi Eric,
>>
>>
>>
>> It's necessary to call Modified() after calling SetPoint() in order for
>> ComputeBounds() to re-compute the bounds.  This is because ComputeBounds()
>> checks the timestamp and does nothing if the timestamp shows that the
>> previous bounds are still good.
>>
>>
>>
>> As far as I understand, vtkPoints has behaved this way for many years.
>> Recently, however, there have been many changes to the VTK rendering
>> pipeline that increase the reliance on timestamps. Perhaps in VTK 8.0
>> something was triggering a Modified() call or was otherwise forcing a
>> re-computation of the bounds.
>>
>>
>>
>>   David
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtkusers/attachments/20181125/2b9d4080/attachment.html>