Re: Performance garray/glist

[Eric Lemings <eric b lemings lmco com>]

Martin Weber wrote:
> 
> I compared the performance of garray (glib-1.2.8) with STL's vector
> (STLport-4.1b5) by starting with an array of the length 0 and growing
> till 10000000 elements. I am using Visual C++ 6.0 and Windows 2000. Here
> my results:
> garray: 1928 ms; 99 KB
> Microsoft STL: 1652 ms; 99 KB
> STLport-4.1b5: 1350 ms; 99 KB
> Also a wish for new versions. glist is unefficient for certain cases:
> struct GList
> {
>   gpointer data;
>   GList *next;
>   GList *prev;
> };
> You always have to do a gmalloc of your data and then put it's pointer
> into the glist. This costs time and memory. Instead the data should be
> directly included into glist structure like it is done in STLlist.
> Old method:
> GList *glist;
> gint *dat;
> glist = NULL;
> for (i = 0; i < n; i++) {
>   dat = gmalloc(sizeof(gint));
>   *dat = i;
>   g_list_append (glist, dat);
> }
> New method with change glib code:
> GList *glist;
> glist = NULL;
> for (i = 0; i < n; i++) {
>   g_list_append (glist, i);
> }
> 
> Here my results:
> Old method: 40 s; 355 KB
> New Method: 4 s; 120 KB
> Microsoft STLlist: 23 s; 235 KB
> STLport-4.1b5: 11 s; 164 KB.
> 
> Please tell me what you think about. Are some of this issues already
> solved in glib-1.3.2?
> 
> Martin

While your results sound good, I don't think this design is possible
with the current GList interface since it would require storing the size
of the data elements somewhere.  The currently implementation doesn't
care what the actual size of the data element is since the only data
element it is concerned with is a pointer.  Implementing a double-linked
list with the data element embedded in the list node would require
additional interfaces or (even worse) interface changes.

Eric.