In article <11**********************@g49g2000cwa.googlegroups .com>,
Cable <tr*********@yahoo.com> wrote:
I have almost
everything worked out but am curious if using fgetc() is the fastest
and most efficient means of reading in data.
It depends on how good the optimizer is.
Generally speaking, when you know you are reading a number of bytes,
fread() is faster, as it avoids the overhead of invoking fgetc()
each time. However, if you have a good optimizer then it might all
come out the same.
Each image is at least
1.1 MB is file size. My main question is: When one uses fopen() does
this just provide a Pointer (via a stream) to the file on disk or does
this actually load the image into RAM and return a pointer to that?
fopen() does NOT read any of the file. The first fgetc() or fread()
or equivilents will read the first bufferful into memory, according to
the size of buffer that has been configured. Subsequent fgetc()
or fread() read out of the in-memory buffer until they get to the
end of it, then read another bufferful, then go back to reading
out of memory, and so on.
The rest of this message gets into non-portable extensions.
Also, can anyone recommend a decent workflow for reading in files very
quickly (the files have to be parsed to retreive the image data as well
as the header info)? My drives are fast enough but I want to make sure
that I am not slowing things down with poor file access.
I have created an app that reads an image from a file then
displays it (using OpenGL)
The OpenGL part is not part of the C standard, so you are already
using non-portable constructs. You need to decide how far into
non-portability you are willing to go. If you find that your
current fgetc() scheme isn't fast enough, and fread() isn't either,
then you should consider using system extensions such as:
- read() -- implemented on all Unix systems and many others
- open( O_DIRECT ) -- in association with read(), allows direct I/O
bypassing system buffers; not supported in all Unixes
- mmap() -- allows a file to be mapped into memory -- possibly more
common than O_DIRECT
- readv() -- allows scatter/gather I/O -- probably not particularily
common
- real-time filesystems such as via SGI's grio extensions and
XFS real-time volumes
- placing the files into a raw partition and handling the filesystem
management yourself
- writing your own device driver
- turning on Command Tag Queuing on SCSI devices
- pre-processing the files into raw data files that can be DMA'd
directly into a buffer suitable for passing to OpenGL
- read the files through once so as to bring their contents into
the system file cache, before starting the graphics process
- figuring out which part of your disk delivers data most quickly,
and ensuring that the files are written to that part of the disk
- when writing the files, figure out about how big they are
going to be, seek to that position, write a byte, and seek
back to the beginning and fill in the data. On many systems,
this will result in contiguous blocks being allocated for the
storage, whereas if you did the standard write of a buffer at
a time, the buffers could end up fragmented all over the disk
- pay attention to time needed to finish processing one file
and open the next, and to the relative positions on disk.
Ideally, when you issue the next read to disk, the disk block
you need should be the very next one that spins under the
head of the current track, so that there is no track-to-track
seek time and no time spent waiting for the appropriate sector
to spin around. This may require fetching information about the
drive geometry -- and for most SCSI disks, geometry is only
an approximation because there are variable number of sectors
per track (outer tracks hold more.)
- issue the largest read request that you can, so that the disk
can read as many consequative blocks as practical
- for SCSI disks, examine the bad-block information so as to
ensure that you aren't seeking wildly to a replacement block
in the middle of an important stream
- if you really get cramped for time, use a solid-state disk
if you can
I'm sure there are many additional disk optimization methods.
See if your OS has a tool named 'diskperf' available for it.
You may have noticed that nearly all of these optimizations are
system and/or hardware specific. The C language itself is
not concerned with filesystem representations or I/O
optimization.
--
"Never install telephone wiring during a lightning storm." -- Linksys