On Sun, Nov 8, 2009 at 5:00 PM, Jan Hudec <[email protected]> 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 < > [email protected]> > _______________________________________________ > Vala-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/vala-list >
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
