Re: File Size and long longs...
Re: File Size and long longs...
- Subject: Re: File Size and long longs...
- From: "b.bum" <email@hidden>
- Date: Wed, 12 May 2004 21:30:53 -0700
On May 12, 2004, at 6:46 PM, Wade Tregaskis wrote:
Although an idiom I often see, you generally should *not* seek to the
end of the file to get the size, since this is not guaranteed to be a
no-op/constant time operation.
Well, to be fair, where would you see a FS these days that doesn't
operate in this manner? All the significant Unix/Linux FS's that come
to mind are i-node based. I'm not sure what HFS+ uses, but I'm sure
it's something similar (or at least B-tree based, iirc, which is still
good enough).
Although having said all this, it is of course ultimately a better
method to just retrieve the file's size directly. It's just not that
bad to fall back to the seeking method.
Not entirely true...
Accessing the attributes for the file is just a matter of grabbing the
information about the inode, the directory entry, or whatever. Even if
seeking is ultra-efficient, you still have to open and close a file
descriptor. File descriptors tend to be fairly expensive in nature,
hence the limit on the number of open file descriptors per process and
per system.
In the big picture, it is likely a completely irrelevant performance
hit. Heck, opening the file and using a for() loop + getc() until EOF
is likely "cheap enough" for *most* applications. (Well, maybe not...
but you get the idea).
For some filesystems, opening the file and seeking to the end may be
several orders of magnitude slower than grabbing the filesize directly
through other means. Three situations come to mind:
- on WebDAV, seeking to the end of the file will likely require
downloading the entire file to the local cache prior to the seek.
Even if it doesn't -- even if the WebDAV client can deal with
downloading ranges AND the HTTP server supports ranged GET methods-- it
is still really expensive to effectively "open" a file on a WebDAV
server
- on compressed or encrypted disk images, you will very likely trigger
a decrypt and/or decompress action by opening the file or performing
the seek. Maybe the filesystem is optimized, maybe it isn't.
- for filesystems on slow media like CDs, flash memory or -- even --
spun down secondary hard drives, opening the file may trigger a round
trip to the media that requires a power up, a potential spin up, and a
read.
So, sure, modern fixed media primary storage devices are generally very
fast and well optimized for something as simple as "open and seek", but
there are all kinds of secondary storage systems or filesystem layering
that would make it extremely expensive to do the additional I/O.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.