Hi, In real life one often has to debug problems.
For this one needs to turn TeX tracing on. 99% of the time I do \tracingmacros1, here in this minimal example I will use trace package and its \traceon \documentclass{article} \usepackage{trace} \begin{document} \traceon \makeatletter \count@ 1000 \loop \ifnum\count@ > 0 \advance\count@ -1 \repeat \traceoff \end{document} when executed in a command line terminal, $ time pdflatex testauctexwithtrace .... many lines of tracing output ... (./testauctexwithtrace.aux) ) (see the transcript file for additional information) No pages of output. Transcript written on testauctexwithtrace.log. real 0m0.142s user 0m0.112s sys 0m0.020s And with 1000 replaced by 11000, I get $ time pdflatex testauctexwithtrace .... many lines of tracing output ... (./testauctexwithtrace.aux) ) (see the transcript file for additional information) No pages of output. Transcript written on testauctexwithtrace.log. real 0m0.460s user 0m0.350s sys 0m0.094s allowing me to estimate the real cost of the lines in log with 1000 iterations to about (0.35-0.11)/10 = 0.024s and this includes the time by system to print to terminal... But I have run this from an Emacs buffer the first one takes about 5 seconds and the one with 10000 iterations about 50 seconds. In real life I very often encounter situations with about 10 seconds extra compilation time. And this, I have to do many times in a row, sometimes. So this builds-up to significant amount of waiting time. Could AUCTeX parsing of log output be delayed until after the TeX run completes ? Any source leading to voluminous logs creates significant slow-down compared to running the TeX run directly in a command line shell. This can already be felt when loading many packages or having many font-encodings in pdflatex with utf8 Best, Jean-François _______________________________________________ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex