[vtkusers] vtk vs pyvtk vs coin3d memory usage

[David Gobbi]

Hi Zach,

Well, most people begin their vtk-python programs with "import vtk", which
loads the python bindings for every VTK class (around 2000 classes).  So,
yes, importing all the python bindings for VTK is going to eat a lot of
time and memory compared to a lean package like Coin3D.  It's possible to
speed up the start time by importing only the VTK modules you need.

VTK can use a lot of memory... the default is for each stage in the filter
pipeline to cache a copy of the data set, and VTK provides almost no
facilities to do in-place manipulation of data.  The python wrappers don't
add any significant weight here, though, it's the same when people write
VTK programs in C++.

With regards to comparing VTK and Coin3D, don't forget that VTK's role is
complex pipelined data manipulation.  Coin3D, as far as I understand, is
focused mainly on getting the data from disk to screen, providing a scene
graph, and providing interaction tools.  So it's a bit of an apples to
oranges comparison.

 - David


On Fri, Jan 15, 2016 at 8:00 PM, Zach <zachnap at gmail.com> wrote:

> Hello:
>
> I was reading through the IVuPy <http://ivupy.sourceforge.net/> page
> regarding comparisons between vtk and coin3D. It mentioned that the python
> implementation (I assume) of vtk used significantly more memory than
> coin3D. Here is the statement:
>
> "A program using the Python bindings of VTK <http://www.vtk.org/> needed
> an order of magnitude more memory and time than a C++ program using Coin3D
> to display the surfaces. The author of the VTK based Python program may not
> have seen how to handle large dat
> <http://www.vtk.org/Wiki/VTK_FAQ#How_to_handle_large_data_sets_in_VTK>a
> sets in VTK
> <http://www.vtk.org/Wiki/VTK_FAQ#How_to_handle_large_data_sets_in_VTK>,
> but Coin3D got it right by default."
>
> So, I am wondering if this is simply a case of the difference in speed
> between C++ and Python; or if it is actually a case of proper
> implementation of Python wrappers, has this issue been remedied? Thanks for
> the help.
>
> Regards,
>
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160115/173b3188/attachment.html>