[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: FW: srlua extension to run with glued zip file
- From: Jay Carlson <nop@...>
- Date: Wed, 05 Jan 2005 21:40:04 -0500
André de Leiradella wrote:
I'm confused. Why don't you just use the linker to put in the data
that you want? The most portable way to do this is just stuff
everything into a const char and compile it. If you want to skip
the octets->.c->.o overhead I suppose you could use objcopy to go
directly from octets->.o, or use a linker script for more control.
One problem with that is that your char array will seat in RAM even
after it has been compiled by Lua, which looks like a waste. Reading
from somewhere (a file, a chunk of data at the end of the executable or
a Windows resource, be them compressed or not) does not waste memory.
That's not true. On any modern desktop or server system, executables
are demand-loaded. Anything read-only and only touched once, like that
const char, is an good candidate for the OS to just drop, in the same
way that it drops caches of files. Files hang around in memory after
you read them too...
This does depend on a little on OS cache tuning. Some kernels
prioritize retaining mmap'd pages (like from executables) over retained
caches of files. But it's only a matter of degree.
I suppose you could provide a stronger hint to the kernel by calling
madvise, or munmap the data after you were done. You'd have to be
careful how you set up the latter of course.
My first real C programming experiences were on the Amiga and MS-DOS
where what you said is true. I continue to find the physical memory
usage on demand paged operating systems to be unintuitive.