[vtk-developers] Speeding up `import vtk`

[Jean-Christophe Fillion-Robin]

Hi Utkarsh,

Good point.

Disabling import using vtkConfig is not a good idea for the reason you
mentioned.

That said, I still like the idea of implementing lazy loading by default
and having vtkConfig to disable it.

> currently be easily provided by factory or other singletons in VTK
library itself that control the default render window created

Good point.

Would it roughly work like this:

  from vtk import vtkSomeFactory
  vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")

or like this:

  from vtkmodules import vtkSomeFactory
  vtkSomeFactory.SetDefaultClass("vtkNameOfSomeClass")

  import vtk


Based on the proposed implementation for vtk.py [1], looks like the second
case is correct.


[1]
https://gitlab.kitware.com/vtk/vtk/merge_requests/3674/diffs#95bcbb4f764974495db2df50144d2e041a3373f3


On Fri, Dec 15, 2017 at 8:55 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> JC,
>
> I am not a huge fan of this option since the `vtk`package will not
> provide a consistent interface based on how the package was imported.
> It will make it impossible to write scripts that use `import vtk` and
> work reliably. e..g say I have a module (outside VTK) that relies on
> `import vtk` to have all necessary symbols. Now my script will fail,
> if some other module that the user imported before importing my module
> changed the nature of the `vtk` package. Thus, the only way to write
> reliable scripts is to import internal modules as needed, and that
> defeats the purpose.
>
> The future config you envision could currently be easily provided by
> factory or other singletons in VTK library itself that control the
> default render window created, for example, and should indeed be
> supported there since it's useful for C++ users of VTK too.
>
> Utkarsh
>
> On Fri, Dec 15, 2017 at 12:04 AM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
> > Hi Utkarsh,
> >
> > I would prefer to have a more generic way of configuring the import
> > behavior.
> >
> > The idea would be to have two top-level packages:  vtk and vtkConfig
> >
> > To skip  loading of all module, you would do:
> >
> > -------------------
> > import vtkConfig
> > vtkConfig.VTK_MODULE_IMPORT = vtkConfig.EXPLICIT   #  Default would be
> > vtkConfig.ALL.  Later we could also have vtkConfig.LAZY
> >
> > import vtk
> > -------------------
> >
> > This would allow to keep things coherent for our user. Naming the package
> > "vtkmodules" seem unconventional.
> >
> > It would also have the advantage of support addition of new option.
> >
> > For example:
> >
> > vtkConfig.RENDERING_METHOD = vtkConfig.OFFSCREEN  #  or vtkConfig.MESA,
> ....
> >
> > Jc
> >
> >
> > On Tue, Dec 12, 2017 at 4:55 PM, Utkarsh Ayachit
> > <utkarsh.ayachit at kitware.com> wrote:
> >>
> >> On Tue, Dec 12, 2017 at 3:18 PM, Ben Boeckel <ben.boeckel at kitware.com>
> >> wrote:
> >> > On Tue, Dec 12, 2017 at 15:06:15 -0500, Prabhu Ramachandran wrote:
> >> >> Would `vtkm` be a shorter name rather than `vtkmodules`?
> >> >
> >> > `vtkm` is a different project already (though I don't know of its
> status
> >> > with Python wrapping outside of the VTK filters which use it).
> >>
> >> Yea, alas `vtkm` won't be a good option.
> >> _______________________________________________
> >> 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:
> >> http://public.kitware.com/mailman/listinfo/vtk-developers
> >>
> >
> >
> >
> > --
> > +1 919 869 8849
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://vtk.org/pipermail/vtk-developers/attachments/20171215/5058cfc6/attachment.html>