Xref: utzoo comp.lang.c:15448 comp.std.c:670
Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!rutgers!apple!desnoyer
From: desnoyer@Apple.COM (Peter Desnoyers)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: BIT Counting: C programming problem
Message-ID: <23833@apple.Apple.COM>
Date: 12 Jan 89 17:51:43 GMT
References: <225@tityus.UUCP> <35329@think.UUCP> <1310@skinner.nprdc.arpa>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 15

In article <1310@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes:
>In article <35329@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes:
>>I haven't seen anyone so far suggest the far end of the time/space
>>trade-off: have a 64K table, with each element N containing the number
>>of bits in N  . . .

More thoughts on large tables and program load time - if the disk the
program is running off of is slow, it may be faster to initialize the
table by calculating it (using a slower algorithm) than to load it as
part of the code. (!) Someone suggested in email that load overhead is
avoided with shareable libraries - it is not, unless another process
is already using that function. The library still resides on disk
before being faulted in.

				Peter Desnoyers