Re: changes in 'require'

[Mike Pall <mikelu-0507@...>]

Hi,

Roberto Ierusalimschy wrote:
> > Maybe it is the price for an extra search that bothers David. 
> 
> Does anyone know how much is that price? As far as I can guess it seems
> to be much smaller than the price of loading the module itself (assuming
> a typical .lua module).

A failed fopen() is pretty cheap, because no buffers are allocated
and the underlying syscall (either open() [POSIX] or CreateFile()
[WIN32]) is quite fast if the path is not there. Still it should
be avoided, if possible (i.e. keep the paths short).

OTOH the double fopen()+getc() for successfully loaded modules
is _not_ cheap. The file buffer is allocated twice by libc
and this involves quite a few syscalls:

open("./foo.lua", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7feb000
read(3, "module(...)\n", 4096) = 12
close(3)              = 0
munmap(0xb7feb000, 4096) = 0
open("./foo.lua", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7feb000
read(3, "module(...)\n", 4096) = 12
read(3, "", 4096)     = 0
close(3)              = 0
munmap(0xb7feb000, 4096) = 0

Yes, this happens for _every_ Lua module that is loaded via
require() (or loadfile() with a search path).

I know the argument about access() being non-ANSI C (and the
_access emulation on Windows is touted to be unreliable).
So a better solution would be to pass the opened FILE* around.
Or at least to drop the getc() (*).

(*) Umm yes, I can live with an error when open() succeeds,
    but the read does not -- this can only happen when someone
    screws up the search path or creates directories named like
    lua modules. Masking this kind of setup errors is not helping
    either.

Bye,
     Mike