Re: glib hash memory footprint

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 (, 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?

Davi de Castro Reis

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