Le 30/04/2015 22:01, Tassilo Horn a écrit :
jfbu <j...@free.fr> writes:
To Tassilo: we see some duplicate kpsewhich calls above. Could there
be a way to do them only once and store the result? This would divide
by 2 the loading time of AUCTeX on systems where kpsewhich is slow.
Well, of course caching would be possible. But you should pinpoint the
bottleneck first, e.g., by using the profiler as I've described in my
first reply to Stefan. I can hardly imagine that kpsewhich is so slow
on Mac/Windows.
I did try the profiler as you described to Stefan, but got no results:
the first method about hitting C-g only ended up in stopping things
but would not get me into the debugger; the second method gave me
a few lists of compiled functions, but nothing that I could truly
relate to the observed time lag.
The time taken up by loading AUCTeX on C-xC-f for the first time
a file foo.tex, is exactly explained by 9 calls to kpsewhich each
taking about 0.55 seconds, for a total of 5 seconds.
Here on real operating system (SCNR) and TeXLive 2014
(benchmark-run 50 (TeX-tree-roots))
takes 5.84 secs. `TeX-tree-roots' calls `TeX-tree-expand' to expand 4
paths, i.e., the benchmark above performs 200 kpathsea calls in under 6
seconds on my laptop. Ok, I have an SSD now but had no AUCTeX load
problems on my older system, too.
My Mac OS X laptop has a SSD and is a *very fast* operating system.
But I executed with M-: (benchmark-run 50 (TeX-tree-roots))
and got
(17.778738 0 0.0) with TeXLive 2015
and ... hold your breath...
(100.477843 1 0.01661499999999999) with TeXLive 2014
The implementation of kpsewhich from TL2014 and earlier had some
issues which I signaled to the community in the fall of 2014 and
which were addressed very efficiently by Adam Maxwell who divided
by 6 the running time.
http://tug.org/pipermail/tex-k/2014-October/002564.html
https://email.esm.psu.edu/pipermail/macosx-tex/2014-October/053020.html
It may be the case that Mac OS X users rarely do their
TeX work on Emacs+AUCTeX and that I may be almost the only
one on Earth. Thus the issues with kpsewhich
remained hidden for some years.
On an older machine, Adam reported to me that my 0.5 second
were 1.5 seconds on his ! just for _one_ call to kpsewhich !
on such a machine AUCTeX 11.88 would need 15 seconds to launch !
Your benchmark above would take 5 minutes to complete !
As I tested this afternoon, AUCTeX 11.86 did only 2 calls
to kpsewhich, thus the loading time would have been bearable then.
If no more reports surfaced, it is, I assume, testimony to the
fact that few people are using Mac OS + Emacs + AUCTeX 11.88
are they are not using a complete TL201x distribution, because
the slowness of kpsewhich is related to the size and number of
the ls-R files
Mac OS X might not be the priority for projects like TeXLive
who try to be multi-system but mainly benchmark on Linux with
some big efforts towards Windows as well, and not too much
attention to Mac OS X which is a Unix after all
For years I was stuck with 10.3.9 as my G4 chip did not
allow system upgrade. Things like updmap-sys would take
dozens of minutes back then.
Also for many years I was stuck with an old AUCTeX because
each time I tried to install anything more recent than
11.85 on my mac os x I always got into big problems and
things not working.
It is only since last fall that I installed 11.88 and hence
could get some more up-to-date release of AUCTeX.
However I immediately noticed the slow loading, although
at that time I did not think of a connection with the
kpsewhich issue which I had also discovered independently.
Independently of the Mac OS X problems, there is something
which is not right in the AUCTeX 11.88 calls to kpsewhich
and this applies to Linux too
Indeed on the 2010 old Linux box I tested this afternoon
things are OK because I have AUCTeX 11.86 and it is loaded
during Emacs launch. If I were to install a more recent
Emacs, and AUCTeX 11.88 via ELPA, I would get the same
payload as on my mac os with TL2015, that is about 1 full
second to load auctex.
best wishes
Jean-François
_______________________________________________
auctex mailing list
auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/auctex
