Re: TODO for GLib 1.4
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: gtk-devel-list redhat com
- Subject: Re: TODO for GLib 1.4
- Date: Mon, 17 Apr 2000 11:28:41 +0200
> > * 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
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
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
> I would say that the right way to fix this would be
> to introduce, say:
> 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:
> 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 */
Sebastian Wilhelmi | här ovanför alla molnen
mailto:email@example.com | är himmlen så förunderligt blå
] [Thread Prev