Re: glib hash memory footprint

On Tue, 2004-08-31 at 22:49, Davi de Castro Reis wrote:

> Since there are too many options and too many tradeoffs/scenarios, my 
> suggestion would be to go with a polymorphic implementation using a 
> union. So you create your hash using g_hash_table_new (linked list), 
> g_hash_table_linear_probing_new(), g_hash_double_hashing_new(), 
> g_hash_array_new() and so on. Then you simply feed the returned pointers 
> to the common methods (ex: g_hash_lookup()) and let the first byte of 
> the union demultiplex the correct call.

The general rule we've followed in GLib is that exposing minor
data structure differences or implementation details to the user
is wrong. We've consistently, for example, rejected requests to
add GRBTree to go along with GTree. (Which is an AVL tree.)

If you can't give a clear and convincing description of why you
should use container A or container B in 10 seconds, then the difference
between the containers isn't worth worrying about for virtually all
application programmers. And it's not worth bloating GLib to have

If a linear probing hash table is actually better for most applications,
then we should just change GHashTable to use it. The way to demonstrate
this is to look around at how GHashTable is used in applications,
GLib, GTK+, write some benchmarks that resemble those use cases,
and show comparisons of speed / memory usage.

If a linear probing hash table is only better for a million entry
hash table, then probably you should just include your own hash
table in your application.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]