Re: [Vala] Array of structs OR Array of classes

[Feng Yu <rainwoodman gmail com>]

On Sun, Nov 8, 2009 at 5:00 PM, Jan Hudec <bulb ucw cz> wrote:

> On Sun, Nov 08, 2009 at 11:58:39 +0100, JM wrote:
> > Hi Jan
> > Thanks for reply!
> > This raises a few more questions for me:
> > > > Would there be an advantage/disadvantage for me to use classes
> instead
> > > > of structs? I need no additional features of these classes.
> > >
> > > Depends on the size of the structures and number of reallocations (due
> to
> > > extending the array). If the structure is small (yours seems to be),
> the copy
> > > will be faster than the allocation, so structures will be better. If
> they get
> > > bigger, the copy time will start to grow and classes start to be
> better.
> > My structs look like this:
> > public struct MyData {
> >     public string A;
> >     public string B;
> >     public string C;
> >     public string D;
> >     public uint E;
> >     public uint F;
> >     public int G = 0;
> >     public string H;
> >     public string I;
> > }
> > Is this a small structure in your understanding?
>
> Performance-wise, I tend to think it is, but you'll have to test. It
> depends
> on too many things.
>
> Memory-wise no, but the improved locality might still make it better,
> especially if you iterate over the array a lot.
>
> > The reallocations are coming only from extending the array when I append
> > new MyData structures. I'm using arrays with typically between 20 and
> > 500 members.
>
> 500 is a tiny number for modern computers. Unless you actually have
> performance problem, just don't bother.
>
> > So basically, this a comparison of the copy time when passing on the
> > array and the allocation time for the classes when creating the array,
> > right?
>
> It's always creation. When passed to functions by default no copy is made
> (since parameters are unowned). A copy is made if you store it in another
> object, though, since members are normally owned.
>
> You have to take into account that for class array some copying still
> occurs
> -- the pointers are still copied.
>
> > > The array also uses up to twice the memory you need, because it's
> allocated
> > > in powers of two.
> > Why do arrays use twice the memory I need?
>
> They use *up to* twice the memory you need, because they are always
> reallocated to double of the previous size.
>
> They do this to maintain constant complexitiy of addition. If the array is
> reallocated to doubles, each added member is only copied (at most) twice
> because of reallocations, no matter how big the array. If the reallocation
> only added constant space, the content would be copied more often the
> longer
> the array is, making the addition complexity linear.
>
> > If I use the compact classes as a replacement for the structs, do I have
> > to set each array member and the array itself to null after usage. Or is
> > there some kind of memory management for these kind of classes? Or
> > better use classes that are not compact but do not inherit from
> > GLib.Object?
>
> Memory-management should work for everything unless you explicitly use
> pointers.
>
> [Compact] class means, that it is not registered with the type system, so
> it
> does not support typeof, can't be used with generics and is a bit smaller
> because it does not contain a GTypeInstance member. [Compact] seems to be
> only recognized in .vapi, so this is irrelevant for you.

Two corrections. Since some time ago:


[Compact] is also recognized in .vala and is compiled into C structs without
a GTypeInstance member. This portion of the compiler might be buggy though.



> Normal class (not derived from Object) has memory management and all that
> stuff, but cannot have properties and signals. They are however smaller
> than
> the ones derived from Object.

Normal classes can also have properties and signals in the VALA sense. The
properties are not registered with GObject system though.

These two are relatively new features, although I have been using them for a
while.



Yu

> --
>                                                 Jan 'Bulb' Hudec <
> bulb ucw cz>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list