Re: changes in 'require'
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: changes in 'require'
- From: Mike Pall <mikelu-0507@...>
- Date: Fri, 8 Jul 2005 20:39:29 +0200
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