[ Quoting Steve Steffler to Scott Little ] 
 SL> fast = big.
 SS> HA!  That's VERY rarely true.
It's OFTEN true,
 SS> The smaller and more efficient the code is, the faster it runs and the
 SS> less memory it uses, assuming the programmer is half decent.
It does depend on what you are doing. When working with limited resources,
such as a slow video card, smaller faster. But with decent resources, bigger
is much faster.
-----------------------------------------------------------------------------
Some examples (true for both C and Pascal). Example 1:
Reading lines from a Unix format text file (CRs, no LFs). The shortest way is
to read one byte from the file at a time, check to see if it's a CR, if not,
it's added to the end of a string variable (and the above repeats), if it is
a CR, the string is then processed and the routine repeats itself until all
the lines are completed.
The longer way is to read a chuck of data from the file, and process it in
memory, similar to the above.
The differene in the source is around 2 pages (50 lines). The difference in
the compiled code is around 800 bytes - the larger being the latter, longer,
method. The difference in speed of the two is also in favor ofthe longer
method. Almost twice as fast.
Example 2:
I have two sort algorithms here. A bubble sort, and one thats called a
MergeSort (thats what the author called it anyway).
The test is, sort 20,000 random integers, and output the results to a file.
Mergesort   - uncompiled: 220 lines
              compiled  : ~5000 bytes
              sort time : 22 hundredths of a second
Bubble Sort - uncompiled: 45 lines
              compiled  : ~3000 bytes
              sort time : 90 seconds and still not finished
-----------------------------------------------------------------------------
In the above two examples, bigger is faster.
Regards,
 - Scott
[ admin@cyberia.asstdc.com.au | www.asstdc.com.au/~cyberia ]
--- FMail/Win32 1.22
3:712/848)
---------------