[Insight-developers] itkVector, itkPoint and vnl_vector

[Will Schroeder]

Hi Folks-

Several other people have expressed concern regarding the 8-byte overhead 
of the
itkPoint/itkVector using vnl_vector_fixed. (Remember, this is 8-bytes out 
of 12-bytes
that a 3D float point would be required to have, a 67% overhead!)

I'm more convinced that this is a real problem. Bill Hoffman is 
communicating with the
vnl people to see about reworking vnl_vector_fixed, because quite frankly 
its overhead
IMHO seems to be a design problem (its inheritance introduces the problem).

Maybe we can spend a little time on Friday talking about this.

Will

At 03:43 PM 1/3/2001 -0500, Luis Ibanez wrote:
>Will Schroeder wrote:
>
> > Hi Jim-
> >
> > In that case I would argue that itkVector should not
> > be implemented with vnl_vector :-) I think memory issues
> > are very important. My experience with big data sets
> > is that the difference between choosing one package over
> > another often boils down to its performance when the data
> > is large, which is usually a function of memory as the
> > system strains to swap, etc.
> >
> > Will
>
>Given that a lot of this will be used only in 2D and 3D
>maybe it could be worth to specialize a set of (Vector,
>Point, AffineTransformation) for 2D/3D without using
>vnl_vector's (to respect the memory constrains), and keep
>a generic set (Vector,Point AffineTransform) for N-D
>using the vnl_vector.
>
>
>The extra bytes that vnl_vector costs will be less
>significant in higher dimensions, and it is in those
>higher dimensions that we don't want to do matrix
>multiplications 'by hand'.
>
>
>If the same API is maintained for both sets, that
>could be a balance between speed, memory usage
>and code reuse.
>
>
>Luis
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers