Re: TODO for GLib 1.4

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> Hi everyone,
> 
> here is my personal TODO list for GLib 1.4
> 
> I really hope, you are going to comment on this a little. I also appended
> default actions, I'm going to take, if noone complains within the next week.
> These are marked with '-->'
> 
> * Rename g_queue_create to g_queue_new. There are so far only two create
>   functions in GLib: g_mem_chunk_create, which is a macro shorthand for
>   g_mem_chunk_new and g_thread_create. The latter is not only a datatype, thus
>   I think create is justified. But queue is a normal datatype like a hashtable
>   for instance, so I would really prefer naming it _new to not repeat the
>   _destroy/_free confusion saga.
>   --> Rename g_queue_create to g_queue_new

Sounds good. Please go ahead with this.

(We do need actually need to figure out a canonical answer for free vs. destroy
so new data types at least are consistent.)

> * 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 seco
>    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%.

> * 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. 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.

> 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.

> 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().

Regards,
                                        Owen