<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;"><br><div><div>Le 1 mai 2015 à 01:05, Norbert Preining <<a href="mailto:preining@logic.at">preining@logic.at</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div><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>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></blockquote><div><br></div><div><br></div><div>There must be at least one initial hard-coded path no?</div><div>I can't relocate kpsewhich anywhere on my system or can I ?</div><div><br></div><div><br></div><div>Are you sure kpsewhich does not do, apart from evaluating the contents of the texmf.cnf</div><div>files, do some un-needed parsing of ls-R files, I mean unneeded when kpsewhich is</div><div>invoked as kpsewhich --expand-path $TEXMFHOME (or whatever)?</div><div><br></div><div>This is why I suggested providing a separate utility to provide only that service of</div><div>identifying the locations of the repertories: where is the DIST tree?, where is the LOCAL tree?,</div><div>where is the HOME tree? </div><div><br></div><div>It appears that there is no issue if the user has set-up corresponding environment</div><div>variables. </div><div><br></div><div>But in that cas TeXLive installation's manual should be explicit about it. I am sure</div><div>this brings other complications.</div><div><br></div><blockquote type="cite"><div dir="auto"><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></blockquote><div><blockquote type="cite"><div dir="auto"><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></blockquote><br></div><div><br></div><div>I did that naturally when I had the problem :</div><div><br>TEXMF_local = $(shell kpsewhich -var-value TEXMFLOCAL)<br><br># as kpsewhich is very slow (.5s) I want to evaluate once only.<br>installlocal: xint.tds.zip<br><span class="Apple-tab-span" style="white-space:pre"> </span>$(eval $@_tmp := $(TEXMF_local))<br><span class="Apple-tab-span" style="white-space:pre"> </span>unzip xint.tds.zip -d $($@_tmp) && texhash $($@_tmp)<br><br></div><div><br></div><blockquote type="cite"><div dir="auto"><div><br></div><div>I would invest time in other, that is to say possible, optimizations.</div></div></blockquote><div><br></div><div><br></div><div>This is not only a Makefile issue</div><div><br></div><div>If I resuscitated this issue after some months, it is because I discovered yesterday</div><div>that Emacs/AUCTeX 11.88 on Mac OS X very lengthy launch was entirely</div><div>to be explained by its nine calls to kpsewhich.</div><div><br></div><div>Earlier AUCTeX 11.86 did only 2, and furthermore it happened during initial</div><div>launch of Emacs, not on (first) opening a .tex file</div><div><br></div><div>With 9 calls to kpsewhich, on my (comparatively quite fast, with SSD) MBA with</div><div>Mavericks and TeXLive 2014, this meant a 5 seconds wait when first launching AUCTeX 11.88</div><div><br></div><div>On an older Mac machine, as the one Adam Maxwell tested my October 2014 findings</div><div>about the slowness of kpsewhich --var-value TEXMFHOME, it would have been 15 seconds.</div><div><br></div><div>With my machine and TeXLive 2015, we go from 5 seconds to less than 1 second</div><div>thanks to the work of Adam Maxwell into improving the Mac OS X speed of</div><div>kpsewhich.</div><div><br></div><div>Currently, the AUCTeX maintainers are taking into accounts these findings</div><div>(this is ongoing) and already yesterday they had reduced from 9 to 5 the number of</div><div>kpsewhich calls, thus halving the launch time</div><div><br></div><div>I try to get them to make only 1 such call, querying all variables</div><div>simultaneously as is allowed by kpsewhich</div><div><br></div><div>see</div><div><br></div><div><a href="http://lists.gnu.org/archive/html/auctex/2015-04/msg00043.html">http://lists.gnu.org/archive/html/auctex/2015-04/msg00043.html</a></div><div><br></div><div>and next messages from that thread</div><div><br></div><div>Let me explicitely mention to people reading this thread that </div><div>this issue does concern also Linux boxes, but may well be hidden to most</div><div>because their TeXLive installation has set-up environment variables</div><div>for TEXMFLOCAL, TEXMFHOME, etc...</div><div><br></div><div><br></div>best</div><div><br></div><div>Jean-François</div><div><br><blockquote type="cite"><div dir="auto"><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/">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 id="signature"></span></div><div><br>On May 1, 2015, at 6:51 AM, jfbu <<a href="mailto:jfbu@free.fr">jfbu@free.fr</a>> wrote:<br><br></div><blockquote type="cite"><span></span><br><span>Le 30 avr. 2015 à 23:42, Karl Berry <<a href="mailto:karl@freefriends.org">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>one might need to do things to find packagefoo.sty via the </span><br><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></blockquote></div></blockquote></div><br></body></html>