Re: Efficiently setting up large quantities of constant data

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Thu, 16 Dec 2004 15:52:28 -0600, Larry Kilgallen wrote:

> In article <cpsfjh$fg3$1@news4.zwoll1.ov.home.nl>, Andre <avsaway@hotmail.com> writes:
>> Dr. Adrian Wrigley wrote:
> 
>>> For example, suppose I have a binary file "distances.dat" containing
>>> the (road) distances between 1000 different cities.  This could be a 2MB
>>> file computed by another application. How can I build a single executable
>>> file containing the data and access it from the Ada code?
> 
>> 2. Use a memory mapped file. This way you also get a pointer to the data 
>> and Windows is taking care of loading it into the memory. Data reading 
>> using a memory mapped file is just as fast as putting it in the executable.
> 
> But since he did not say the purpose of putting it in the application
> was for speed, I think we have to presume it was for religious reasons.

It seems like a good idea in some circumstances:

Atomic upgrade - replace the binary in one step may be useful,
particularly in a real-time system (think cron job running single
executable avoids possible inconsistency of old data files during upgrade)

obscures internal structures a bit - makes it a bit harder for users to
mess around with/view internal structure (eg substituting their own data
files)

simpler distribution - can put executable in /usr/bin without messy
directory of data files to go somewhere.  No need for .tar.gz archive.
Also simpler to remove and to verify.

I like the objcopy route over generating and compiling Ada source
(particularly for large data), since it avoids potential compiler limits,
and doesn't risk unexpected efficiency problems (stack space/elaboration
time/code space, compilation time etc.).

but mostly it was religious, yes...
-- 
Adrian