Do you have a use case where hash-table lookups would be a bottleneck?
Small mobile devices. Devices with only 64MB of RAM to play with. Embedded
devices. Just because GLib is used mainly in GNOME don't make the
assumption its the ONLY place. Not every deployment of GLib applications is
on a multi-core CPU system with multi-gigs of memory, or even with
traditional hard disks. Or even hard disks at all. Places where you are
using GLib becuase its relatively small, not using the massive overhead
that is GIO and which serves a different purpose entirely. Just becuase
GLib and GIO come in the same tar does NOT mean they are always deployed
side by side.
With dual-core CPUs we have nowadays, disk access is likely to be much
slower than the hash-table work that GIO produces. And few programs
would need to stat that many files anyway.
Really? On what do you base that information? There are three applications
I want to write that even brought me to the GLib / Gtk+ world and ALL of
them use stat because they are dealing with files. The bottom line is,
although stat may be a low level system call, applications deal with files.
A LOT. A HELL of a lot. stat is a basic file operation. It can be made to
be more portable. That's all I am trying to do. It can abstract 95% of all
of the problem areas. If you have an application that needs very specific,
tied-to-one-OS stat structures then by all means use stat. But when a
*Platform* library isn't abstracting a basic *platform* call, that's a
problem and I don't understand all the resistance to it.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list