[Insight-users] Importing itk module generated by WrapITK is slow

[Gaetan Lehmann]

On Tuesday 28 March 2006 19:50, Zachary Pincus wrote:
> Hi Kalle -
>
> > 1. Enabling WRAP_rgb_unsigned_short in ccmake caused the "import
> > itk" to fail, because the symbol NumericTraits<RGBPixel<unsigned
> > short>> (or something to that effect) was not found.  Disabling the
> > wrapping fixed the issue.
>
> Could you post the exact error if you can find it? I don't think
> we've run into that in testing, and it would be good to get it fixed.

This problem have already been reported by Kent, and I think also fixed by 
Kent in ITK CVs

>
> > 2. import itk from python interpreter takes a lot of time
> > (generally in the range from ~120 seconds to ~150 seconds)
>
> As you might expect, this is because the default WrapITK wrapper
> libraries are huge (look at the size of the shared libs). The delay
> is probably unavoidable when loading several hundred megabytes of
> shared library code. I don't think there's any generally good way to
> speed this up -- but rest assured, we're keeping our eyes open in
> hopes of finding a better solution in the future.
>
> There are two solutions you could use for now:
> (1) Don't use 'import itk' and instead selectively import the
> libraries that you want, e.g.:
> 'import BasicFiltersA' (which will also take care of importing any
> dependencies).
>
> (2) Modify the WrapITK distribution to wrap fewer classes. You should
> feel free to move/rename the any number of the wrap_xxx.cmake files
> from BasicFiltersA, BasicFiltersB, and Algorithms so that they are
> not built. If you want to add those filters in later, creating an
> external project and dropping the wrap_xxx.cmake files into that
> project is a quick and seamless way of getting them in. You can
> choose whether or not installed external projects are automatically
> imported when you call 'import itk'.


I was a bit surprised by the load speed of the tcl modules. I think that's 
because it use real shared libs.
The first run take some time, but the second is very fast. Perhaps can we do 
the same for python in the future - I think vtk already do that

Also, this problem can be a little less annoying with the ImportCallBack 
function which allow to run some code while loading the itk module - look at 
the article for an example. If you're working on a GUI, at least it avoid 
blocking the program to much time.

Can you tell us which types and dimensions you have selected ?

Gaetan


>
> Zach Pincus
>
> Program in Biomedical Informatics and Department of Biochemistry
> Stanford University School of Medicine
>
> > The first problem isn't a problem since I don't really need the
> > datatype. The delay in loading the library on the other hand is not
> > very desirable.
> >
> > I'm not very well versed in using ITK and was looking forward to
> > testing stuff from python. I guess I could do development in a way
> > that the library was kept in memory and once I had something
> > working, only wrap the classes that the code absolutely needs to
> > keep the load time manageable.
> >
> > Is there some other way to speed up the loading of the itk module
> > than cutting down on stuff it contains?
> >
> > Oh, in case it matters my GCC version is
> > gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
> >
> > I'd be happy to describe my setup further if it has anything to do
> > with the issue.
> >
> > Kalle Pahajoki
> >
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20060328/6c744505/attachment.pgp