Hi, Is there any reason to prefer object interface to kpathsea over the procedural one? I'm asking in particular in the context of dofile(arbitrary_script), where arbitrary_script may also use kpathsea (either through procedural or object interface). Cheers, Tomek
T T wrote:
Hi,
Is there any reason to prefer object interface to kpathsea over the procedural one? I'm asking in particular in the context of dofile(arbitrary_script), where arbitrary_script may also use kpathsea (either through procedural or object interface).
The object interface gives you a kpse object that is totally separate from luatex, the procedural interface reuses the kpse that luatex itself uses for its own lookups. Whether the distinction matters to you depends on what you want to do. Best wishes, Taco
2009/12/2 Taco Hoekwater
The object interface gives you a kpse object that is totally separate from luatex, the procedural interface reuses the kpse that luatex itself uses for its own lookups.
Thanks for explaining this.
Whether the distinction matters to you depends on what you want to do.
I'm working on a script wrapper for TL that runs under texlua. As an optimization I want to call (tex)lua scripts directly with dofile to avoid spawning new processes, but I want to make sure that kpse.set_program_name from my wrapper doesn't impact the invoked script in any way. As I understand in this scenario it will be better to use kpse object and keep it local. Does this incur any performance penalty, i.e. does kpathsea reinitializes itself from scratch when my object goes out of scope and set_program_name is called again? Cheers, Tomek
Hi, T T wrote:
Whether the distinction matters to you depends on what you want to do.
I'm working on a script wrapper for TL that runs under texlua. As an optimization I want to call (tex)lua scripts directly with dofile to avoid spawning new processes, but I want to make sure that kpse.set_program_name from my wrapper doesn't impact the invoked script in any way.
As I understand in this scenario it will be better to use kpse object and keep it local.
Probably, but:
Does this incur any performance penalty, i.e. does kpathsea reinitializes itself from scratch when my object goes out of scope and set_program_name is called again?
When a kpse:new() variable goes out of scope or when you want to change its program name you will have to start a brand new one. If you use the procedural interface, kpse.set_program_name() will keep its cnf and databases files in memory, only the rest is reset. This kpathsea never goes out of scope, because it is a global luatex variable. So, for efficiency reasons, you could opt to only reset the program_name via the procedural interface, unless the script updates the database and/or cnf file. Best wishes, Taco
2009/12/2 Taco Hoekwater
Does this incur any performance penalty, i.e. does kpathsea reinitializes itself from scratch when my object goes out of scope and set_program_name is called again?
When a kpse:new() variable goes out of scope or when you want to change its program name you will have to start a brand new one.
If you use the procedural interface, kpse.set_program_name() will keep its cnf and databases files in memory, only the rest is reset. This kpathsea never goes out of scope, because it is a global luatex variable.
So, for efficiency reasons, you could opt to only reset the program_name via the procedural interface, unless the script updates the database and/or cnf file.
Ah, in that case I will stick with the procedural interface, indeed. Database loading makes for the most of the start-up time in my tests and the invoked standalone script has to make its own call to kpse.set_program_name anyway. Thanks for all this info. Cheers, Tomek
participants (2)
-
T T -
Taco Hoekwater