TODO for GLib 1.4

[Sebastian Wilhelmi <wilhelmi ira uka de>]

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
* 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 
* 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.
* 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.
* Regarding Bug #6707: I would just add these reserve functions for arrays.
  --> add them.

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   |

hash_table_freeze_test.c