[tex-k] Speed of kpsewhich when querying the repertories of the TeX installation

[Norbert Preining]

>> If you run kpsewhich --debug=-1 --expand-path=\$TEXMFHOME,
>> you will see what it's doing.
> 
> I am sure kpsewhich does a lot, but does one need to do such a lot
> such to tell where is TEXMFLOCAL and TEXMFHOME and TEXMFDIST ?

Yes, one has to. Otherwise 20 years of expectation would be broken.

People regularly redefine TEXMFHOME and TEXMFLOCAL, and that might even happen on multiple levels (distribution makes first change, system admin another).

So besides:
* reading the main texmf.cnf
* searching for other texmf.cnf
* evaluating their contents
there is only hard coded path, and that is a no-go.


Let us go back to your Makefile: how many var-values do younormally need? 2? 3? Evaluating them once and saving costs 300ms.

Evaluating a complex Makefile with rules is probably more time consuming.

We do this caching of vars in many of our scripts, and that is definitely not the bottle neck.

I would invest time in other, that is to say possible, optimizations.

Norbert
------------------------------------------------------------------------
PREINING, Norbert                              http://www.preining.info
JAIST, Japan                                 TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------

> On May 1, 2015, at 6:51 AM, jfbu <jfbu at free.fr> wrote:
> 
> 
>> Le 30 avr. 2015 à 23:42, Karl Berry <karl at freefriends.org> a écrit :
>> 
>>   I may write a Makefile which will act after querying
>>   the repertories locations. But one tenth of a second
>>   for each kpsewhich call is a lot.
>> 
>> Save the result instead of making the same call thousands of times.  I
>> don't agree that 100 ms is such a horrible time to do all those
>> filesystem operations.  In fact, it seems rather quick to me.
>> 
>>   Could it be imagined to have some kpsewhichdir utility
>> 
>> 1) I fail to see how making a utility restricted to a single variable
>> could speed anything up.  
> 
> 
> I probably did not express myself precisely. I am not targeting
> a single variable; I am targeting the variables describing the main
> repertories of the TeXLive installation
> 
> 
> 
>> Surely what takes the time is looking for the
>> config files in all the possible directories, and (more so) reading the
>> ls-R file.  
> one might need to do things to find packagefoo.sty via the 
> parsing of the ls-R files or system calls to ls, but why would these things
> be needed for the main installation repertories ???
> 
> Perhaps many distributions set up environment variables thus
> the speed penalty is not obvious to these users.
> 
> 
>> 
>> 2) Regardless, the idea of a utility dedicated to a single variable
>> sounds wrong in principle to me and I don't think it should be done.
>> 
>>   the environment variable $TEXMFHOME 
>> 
>> So far as I can see, if the envvar is set, its value is already (has
>> always been) returned "instantly".  The lookups are only done if they
>> need to be.
>> 
>> karl
> 
> 
> I have none such environment variable and do not see why I should
> set some
> 
> Jean-François
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-k/attachments/20150501/da391b68/attachment-0001.html>