Re: TODO for GLib 1.4

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Owen,

> > * Regarding Bug #3883. I would include the following warning into the GLib
> >   reference manual and close the bug (no changes to GLib):
> >     As the hashtable will not be resized during a freeze, it should not
> >     become
> >     bigger then, as otherwise a major performace loss might occur.
> >   Why not remove the freeze alltogether, as proposed in the bug report?
> >   Because I measured it and freezing can indeed speed things up, while it
> >   can yield dramatic performance loss, if used unwisely: A program to
> >   demonstrate this attached. Here are the results:
> >    inserting 10000 elements frozen: 2.619429 sec
> >    deleting 5000 and inserting 5000 elements frozen: 0.021036 sec
> >    deleting and inserting 5000 elements alternating frozen: 0.020796 sec
> >    deleting 10000 elements frozen: 0.027939 sec
> >    inserting 10000 elements unfrozen: 0.033238 sec
> >    deleting 5000 and inserting 5000 elements unfrozen: 0.026019 sec
> >    deleting and inserting 5000 elements alternating unfrozen: 0.028251 sec
> >    deleting 10000 elements unfrozen: 0.027182 sec
> >   --> Remove the bug report, amend the documentation
> 
> I would disagree with this. Basically, it makes things more
> complicated to get marginal gains in a few cases. I think we should
> make things simpler for our users by paying attention to worst-case
> performance. A frozen hash table has HORRIBLE worst-case performance.
> 
> If it made things 10 times faster, then, yes, I would say that it
> would be worth it. But the speedups you have here seem to be order
> 20%.

So you propose to remove the _free and _thaw functions alltogether. Thats fine
with me. Should there still be the functions for compatibility or should I
just remove them? 

> > * Regarding Bug #5097. I would just change g_basename to return a
> > string, that must be freed. This of course could open memory
> > holes. So an alternative might be to rename the function to
> > g_basename2() with the new semantics, remove the old one and rename
> > the function back to g_basename in GLib 1.6, such that everyone
> > using the function is aware of the change.  --> nothing.  *
> 
> Hmmmm, that would still break everybody's code in the 1.4 => 1.6
> transition. 

Do you mean the 1.2=>1.6 transition here? Will such a transition happen? Based
on current experience 1.6 will be out in 2 years. Who will change versions
that late?

> I would say that the right way to fix this would be
> to introduce, say:
>
>  g_path_get_basename()
> 
> that does the right thing, and deprecate g_basename. I'm just not sure
> that this is enough of a problem to be worth trying to fix.

My proposal actually would be to break the semantics of the function and make
a big warning into the transition file and the documentation and fix all
occurences in cvs.gnome.org
 
> > Regarding Bug #928. As I already said in another mail I would add a
> > --enable-memprof-friendly to ./configure and then NULLify
> > everything, that GLib has control to avoid bogus pointer references
> > to memory, you can't reach anymore within your program.  --> commit
> > the patch. This wont hurt GLib at all, just when
> > --enable-memprof-friendly is given, it will become slower.  *
> 
> Yes, this is fine with me. I think I would call it:
> 
>  --enable-gc-friendly
> 
> To be more generic.

Ah, I actually looked for a better name, but didn't find one. That sound nice.

> > Regarding Bug #6707: I would just add these reserve functions for
> > arrays.  --> add them.
> 
> This sounds reasonable. One possible concern is that for a
> zero-terminated array, you get a double alloc then. Another option
> would be to mimic g_string_sized_new() and have g_array_sized_new().

Yes, sounds better. If one really have to resize it later, he could actually
do it like that:

len = array->len;
if (len < reserve_size)
  {
    g_array_set_size (array, reserve_size);
    g_array_set_size (array, len); /* or simpler: array->len = len */
  }

Bye,
Sebastian
-- 
Sebastian Wilhelmi                   |            här ovanför alla molnen
mailto:wilhelmi@ira.uka.de           |     är himmlen så förunderligt blå
http://goethe.ira.uka.de/~wilhelmi   |