g_hash_table_find(), g_hash_table_foreach(): document performance caveats

Mon Jun 25 16:43:13 2007  Tim Janik  <timj@gtk.org>                                                                                                           
                                                                                                                                                              
        * glib/ghash.c: g_hash_table_find(), g_hash_table_foreach():                                                                                          
        document performance caveats for linear order searches.                                                                                               
                                                                                                                                                              


svn path=/trunk/; revision=5587
This commit is contained in:
Tim Janik 2007-06-25 14:44:41 +00:00 committed by Tim Janik
parent ce0ad84a78
commit 2ef43de2af
2 changed files with 20 additions and 3 deletions

View File

@ -1,3 +1,8 @@
Mon Jun 25 16:43:13 2007 Tim Janik <timj@gtk.org>
* glib/ghash.c: g_hash_table_find(), g_hash_table_foreach():
document performance caveats for linear order searches.
2007-06-22 Mathias Hasselmann <mathias.hasselmann@gmx.de>
* glib/gstring.c: Use memcpy in g_string_append_vprintf (#57693).

View File

@ -660,6 +660,9 @@ g_hash_table_foreach_remove_or_steal (GHashTable *hash_table,
* be modified while iterating over it (you can't add/remove
* items). To remove all items matching a predicate, use
* g_hash_table_foreach_remove().
*
* See g_hash_table_find() for performance caveats for linear
* order searches in contrast to g_hash_table_lookup().
**/
void
g_hash_table_foreach (GHashTable *hash_table,
@ -688,6 +691,15 @@ g_hash_table_foreach (GHashTable *hash_table,
* each pair, and the given @user_data parameter. The hash table may not
* be modified while iterating over it (you can't add/remove items).
*
* Note, that hash tables are really only optimized for forward lookups,
* i.e. g_hash_table_lookup().
* So code that frequently issues g_hash_table_find() or
* g_hash_table_foreach() (e.g. in the order of once per every entry in a
* hash table) should probably be reworked to use additional or different
* data structures for reverse lookups (keep in mind that an O(n) find/foreach
* operation issued for all n values in a hash table ends up needing O(n*n)
* operations).
*
* Return value: The value of the first key/value pair is returned, for which
* func evaluates to %TRUE. If no pair with the requested property is found,
* %NULL is returned.