<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">[re-formatting my message, sorry]<div><div>Hi</div><div><br></div><div>this is interesting thanks, but let me again explicitely state</div><div>that my only issue is with querying what TEXMFHOME, TEXMFLOCAL,</div><div>etc.. are</div><div><br></div><div>perhaps this is a no-issue for most people because those are</div><div>already set up as environment variables ?</div><div><br></div><div>as I will comment more in another mail, the issue is acute with</div><div>Emacs/AUCTeX 11.88 which (until now where the maintainers on my</div><div>prompting are starting to issue patches) queries 9 times kpsewhich</div><div>during launch. On a fast Mac OS X with TL2014 this meant a 5</div><div>seconds loading time of Emacs /AUCTeX, entirely caused by these 9</div><div>calls to kpsewhich. Current development branch has already divided</div><div>by 2 this to reduce to 5 calls caching the earlier results. I am</div><div>trying to convince the developers to arrange things to make only 1</div><div>call to kpsewhich simultaneously for all variables, as is</div><div>possible.</div><div><br></div><div>best</div><div><br></div><div>Jean-François</div><div><br></div><div><div>Le 1 mai 2015 à 01:21, Fabrice Popineau <<a href="mailto:fabrice.popineau@supelec.fr">fabrice.popineau@supelec.fr</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">There is a way to speed up things.<div>IIRC most of the time in a kpsewhich call is spent parsing texmf.cnf and reading ls-R files.</div><div><div>Many years ago, I added some code to kpathsea so that internal hash tables be shared among process</div><div>to speed up things when tex calls metapost which calls tex etc.</div><div>Next Karel Skoupy wrote a kpathsea server exhibiting the same kind of speedup, but surely in a more flexible way.</div></div><div>Maybe some of these ideas could be revived.</div><div><br></div><div>Another (simpler) option would be to allow kpsewhich to process several requests, if that can help Jean-François.</div><div><br></div><div>Fabrice</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-01 1:05 GMT+02:00 Norbert Preining <span dir="ltr"><<a href="mailto:preining@logic.at" target="_blank">preining@logic.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span class=""><blockquote type="cite"><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">If you run kpsewhich --debug=-1 --expand-path=\$TEXMFHOME,<br></span></font></blockquote><blockquote type="cite"><font><span style="background-color:rgba(255,255,255,0)">you will see what it's doing.</span></font></blockquote><font><span style="background-color:rgba(255,255,255,0)"><br>I am sure kpsewhich does a lot, but does one need to do such a lot<br>such to tell where is TEXMFLOCAL and TEXMFHOME and TEXMFDIST ?</span></font><br></blockquote><div><br></div></span>Yes, one has to. Otherwise 20 years of expectation would be broken.</div><div><br></div><div>People regularly redefine TEXMFHOME and TEXMFLOCAL, and that might even happen on multiple levels (distribution makes first change, system admin another).</div><div><br></div><div>So besides:</div><div>* reading the main texmf.cnf</div><div>* searching for other texmf.cnf</div><div>* evaluating their contents</div><div>there is only hard coded path, and that is a no-go.</div><div><br></div><div><br></div><div>Let us go back to your Makefile: how many var-values do younormally need? 2? 3? Evaluating them once and saving costs 300ms.</div><div><br></div><div>Evaluating a complex Makefile with rules is probably more time consuming.</div><div><br></div><div>We do this caching of vars in many of our scripts, and that is definitely not the bottle neck.</div><div><br></div><div>I would invest time in other, that is to say possible, optimizations.</div><div><br></div><div>Norbert<br><div><span style="background-color:rgba(255,255,255,0)">------------------------------------------------------------------------</span></div><div><span style="background-color:rgba(255,255,255,0)">PREINING, Norbert <a href="http://www.preining.info/" target="_blank">http://www.preining.info</a></span></div><div><span style="background-color:rgba(255,255,255,0)">JAIST, Japan TeX Live & Debian Developer</span></div><div><span style="background-color:rgba(255,255,255,0)">GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13</span></div><div><span style="background-color:rgba(255,255,255,0)">------------------------------------------------------------------------</span></div><span></span></div><span class=""><br>On May 1, 2015, at 6:51 AM, jfbu <<a href="mailto:jfbu@free.fr" target="_blank">jfbu@free.fr</a>> wrote:<br><br></span><blockquote type="cite"><span class=""><span></span><br><span>Le 30 avr. 2015 à 23:42, Karl Berry <<a href="mailto:karl@freefriends.org" target="_blank">karl@freefriends.org</a>> a écrit :</span><br><span></span><br><blockquote type="cite"><span> I may write a Makefile which will act after querying</span><br></blockquote><blockquote type="cite"><span> the repertories locations. But one tenth of a second</span><br></blockquote><blockquote type="cite"><span> for each kpsewhich call is a lot.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Save the result instead of making the same call thousands of times. I</span><br></blockquote><blockquote type="cite"><span>don't agree that 100 ms is such a horrible time to do all those</span><br></blockquote><blockquote type="cite"><span>filesystem operations. In fact, it seems rather quick to me.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Could it be imagined to have some kpsewhichdir utility</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>1) I fail to see how making a utility restricted to a single variable</span><br></blockquote><blockquote type="cite"><span>could speed anything up. </span><br></blockquote><span></span><br><span></span><br><span>I probably did not express myself precisely. I am not targeting</span><br><span>a single variable; I am targeting the variables describing the main</span><br><span>repertories of the TeXLive installation</span><br><span></span><br><span></span><br><span></span><br><blockquote type="cite"><span>Surely what takes the time is looking for the</span><br></blockquote><blockquote type="cite"><span>config files in all the possible directories, and (more so) reading the</span><br></blockquote><blockquote type="cite"><span>ls-R file. </span></blockquote></span><span>one might need to do things to find packagefoo.sty via the </span><br><span class=""><span>parsing of the ls-R files or system calls to ls, but why would these things</span><br><span>be needed for the main installation repertories ???</span><br><span></span><br><span>Perhaps many distributions set up environment variables thus</span><br><span>the speed penalty is not obvious to these users.</span><br><span></span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>2) Regardless, the idea of a utility dedicated to a single variable</span><br></blockquote><blockquote type="cite"><span>sounds wrong in principle to me and I don't think it should be done.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> the environment variable $TEXMFHOME </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>So far as I can see, if the envvar is set, its value is already (has</span><br></blockquote><blockquote type="cite"><span>always been) returned "instantly". The lookups are only done if they</span><br></blockquote><blockquote type="cite"><span>need to be.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>karl</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span></span><br><span>I have none such environment variable and do not see why I should</span><br><span>set some</span><br><span></span><br><span>Jean-François</span><br></span></blockquote></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Fabrice Popineau<div>-----------------------------</div><div>SUPELEC</div><div>Département Informatique</div><div>3, rue Joliot Curie</div><div>91192 Gif/Yvette Cedex</div><div>Tel direct : +33 (0) 169851950</div><div>Standard : +33 (0) 169851212</div><div>------------------------------</div><div><br></div></div>
</div>
</blockquote></div><br></div></body></html>