| Pete Dashwood 2005-07-25, 10:01 pm |
| Good post, Rick. I appreciate the empirical approach.
Comments below...
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11due6mb9fhfac3@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3k86utFl4gssU1@individual.net...
> them
> in
> the
> that
> so
> code
>
> Perhaps, Mr Dashwood, you had some additional restrictions
> in mind; but there are cases where larger code, with 'identical
> functionality', will execute faster.
>
> The following program has two procedures to determine the
> length of text (a string). The procedures have 'identical functionality',
> in that they each accept a 32 character item and return its length
> (the position of the last non-space character). They also function
> identically by examining the 32 character item, in reverse, one
> character at a time. Yet the larger procedure outperforms the smaller.
This is because the capture time of the smaller module is much greater than
the capture time of the larger module.
The example has been contrived to show this, and it is valid.
I shouldn't have said 'invariably'. It is not invariably so.
My statement was based on my own experience using real world data, and the
teaching I received.
The fact is that load module size directly reduces load time, but it is only
more likely to reduce capture time; it isn't definite.
Your example shows a case where it doesn't help the capture time. I
overlooked this, but I should have been more careful in what I stated.
Thanks for posting the example.
However, I still believe that in a real mix of programs, in an online
environment, small is beautiful.
Pete.
<snipped good example>
|