[vtk-developers] Speeding up `import vtk`

[Berk Geveci]

Are we talking about modules or kits? The two are not interchangeable in
VTK.

On Mon, Dec 18, 2017 at 1:09 PM, Jean-Christophe Fillion-Robin <
jchris.fillionr at kitware.com> wrote:

> Hi Ben,
>
> Here is an updated version of the comment I originally posted on MR 3674
> <https://gitlab.kitware.com/vtk/vtk/merge_requests/3674#note_355306>.
>
>
> Short version:
>
> Having the dependency graph of VTK kits available in python is needed to
> generate cross platform distributable wheels.
>
>
> Long version:
>
> The introduction vtkmodules enables granular import.
>
> In a install or build tree where the PATH, LD_LIBRARY_PATH, ... are set or
> if RPATH is available, importing any specific module will work because the
> dynamic library loader will find the correct dependencies and load them.
> (e.g ParaView, Slicer, ...)
>
> To support generation of distributable python wheels and avoid user to
> compile VTK each time they want to use it, a given compiled python module
> can NOT depends on shared libraries and expect the library loader to find
> them unless:
>
> * the dependent libraries are system ones
> * the compiled python module explicitly loads them in order
>
>
> What does this mean ?
>
> * We need to support building any given kit as standalone kit without any
> dependencies beside of system libraries and symbols from other kit
> * We need to make sure dependent kit are explicitly imported within python
> in the right order
>
>
> Hence the need to have the dependency graph available from python.
>
> There is also other challenges like:
>
> * sharing symbol across python modules (e.g GlobalTimeStamp need to be the
> same for all modules). To address this, we use Python Capsule C/API in ITK.
>
>
> For these reasons, we need to have the dependency graph available.
>
> And once, we have the dependency graph ... supporting lazy loading
> wouldn't be too much work.
>
>
> In the future, support for Native libraries in wheels would alleviate some
> of these issues. In the mean time, it is a necessary evil:
>
> * https://github.com/jcfr/wheel-builders/blob/
> 058287254a139908578501eb70b602e33202720a/pynativelib-proposal.rst
> * https://github.com/pypa/wheel-builders/pull/2
>
>
>
>
> On Fri, Dec 15, 2017 at 12:02 PM, Utkarsh Ayachit <
> utkarsh.ayachit at kitware.com> wrote:
>
>> >>   from vtkmodules import vtkSomeFactory
>> >>   vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")
>> >
>> > This would be `from vtkmodules.vtkSomeModule import vtkSomeFactory`. The
>> > point of vtkmodules is that the top-level package *doesn't* import
>> > everything.
>>
>> You can also:
>> > from vtk import vtkSomeFactory
>> >  vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")
>>
>> Utkarsh
>>
>
>
>
> --
> +1 919 869 8849 <(919)%20869-8849>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://vtk.org/pipermail/vtk-developers/attachments/20171218/585e9939/attachment-0001.html>