Re: _wstat on Windows (actually stat stuff in general)

[Sam Thursfield <ssssam gmail com>]

On Wed, Sep 28, 2011 at 10:27 AM, Kean Johnston <kean johnston gmail com> wrote:
>> 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.

Writing embedded code and writing code that is portable between three
major desktop OSes are essentially orthogonal concerns. Scripting
languages such as Python use hash tables for all their namespace
lookups and as a common data structure - it's not a huge performance
concern.

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

The problem is that stat is API from the 1970's. None of us really
want to prolong the life of code with such readable names as S_IFMT,
S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
up with a fully portable, modern abstraction on top of all this. I for
one would much rather be working with
G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP, G_FILE_ATTRIBUTE_TIME_ACCESS etc.

GLib is a 21st century platform library, not a pile of portability
hacks. I admit that for convenience it's managed to acquire a bunch of
portability hacks, but this isn't a design goal. If you would like to
use GIO but find measurable performance problems or missing
functionality, bug reports are welcome.

Sam