[comp.lang.c] array or pointer

hardbody@milton.acs.washington.edu (Hardbody) (11/17/89)

Suppose I wanted to read 500 records, each of 80 bytes long, from a file,
How should I store them? Should I do

(1) char line[500][80];   since I already know the size of the file.

OR

(2) char *line[500];   But before we could use 'line,' we have to use 'malloc'
                       to allocate memory to the array of pointers.

Which case is faster as far as the time it takes to load the file in is
concerned?

Thanks plenty.

CMH117@PSUVM.BITNET (Charles Hannum) (11/18/89)

If you knew that you always want to read 500 record of exactly 80 bytes, there
is no reason to dynamically allocate the memory.  It should be statically
allocated.  i.e.:

   char foo[500][80];

Note:  I used the words "byte" and "char" interchangeably here.  This may vary
       depending on the implementation.  Unfortunately, most of the compilers
       I've used don't have a "byte" type.

chris@mimsy.umd.edu (Chris Torek) (11/20/89)

In article <709@milton.acs.washington.edu> hardbody@milton.acs.washington.edu
(Hardbody) writes:
>Suppose I wanted to read 500 records, each of 80 bytes long, from a file,
>How should I store them?

You should store them in a way that makes them convenient to manipulate
for whatever it is that you are trying to achieve.  Since you have not
told us what that might be, we cannot give a more specific answer.

>Should I do
>(1) char line[500][80];   since I already know the size of the file.
>OR
>(2) char *line[500];   But before we could use 'line,' we have to use 'malloc'
>                       to allocate memory to the array of pointers.

(not necessarily true---you could, e.g., write

	static char l[500][80];		/* line data space */
	char *line[500] = {
		l[0],l[1],l[2],l[3],l[4],l[5],
...		l[499]
	};

which allocates lines without using malloc.)

>Which case is faster as far as the time it takes to load the file in is
>concerned?

Neither.  The time to load the file depends on the code used to load the
file, the layout of the file on its underlying storage medium, and many
other points which are to varying extents unaffected by the format used
to store the data for manipulation.  The first format is more convenient
for a C-style fread call, which might or might not be significant.

Since 500*80=40000 and since char is typically one byte and since 40000
bytes is typically so small that the time to read the file is lost in
the noise, if your program does anything significant with the lines,
the time it spends will be dominated by that code and the code used to
read them will be insignificant.  On a typical 1 MB/s SCSI disk (size
range .5 to 2 GB%), for instance, if you read 40000 bytes from contiguous
sectors you may not even incur a track-to-track seek, so that the 40k
would take (40k/1M)+(overhead) seconds, i.e., around 0.04 s.

Of course, if you are stuck with an IBM PC XT with a single density
floppy, the picture will change.
-----
% The gigabyte 2-inch drives are not out yet, but there is plenty of
  smoke.  The 1.5 GB drives *are* out, reliability as yet unknown.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris