Re: glib hash memory footprint

[Davi de Castro Reis <davicastro terra com br>]

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

Well, I can point two. It uses too much memory. It is too slow to 
destroy. But I already got your point when Keith Packard said that glib 
should not be a data structures text book.

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

Well, I don't think I am capable of doing it, because, although I do use 
glib extensively, I am not a GTK+ programmer. Even if I could, I don't 
see with good eyes changing a fundamental structure implementation that 
has been around for so many time. Some applications might benefit, 
others not. So, if the union solution is not welcome (and I do 
understand the reasons), everything should stay as it is now.

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

Yes, that is probably the way to go. I opened a bugzilla entry for this 
discussion (http://bugzilla.gnome.org/show_bug.cgi?id=151615), and, if 
you agree, I  will paste some of the e-mail discussion there and change 
it to documentation bug, so people will easily see that glib's hash is 
not suitable for large hash tables. Do you think that this is a good 
solution?

Thanks,
Davi de Castro Reis