6

Compiling a 130 pages long report with xelatex takes my PC about 4 seconds, of which at least 1 second is spent at one particular page, and some more time at a later page.

The page where most time is spent is one in a sequence of very similar pages, all ending with a \clearpage command; hence there are no issues with line/page breaks or float placement. The page contains formulae and figures, but so do many other pages before and after. Of course I have checked the size of the figures: no different from those on other pages. Of course I have looked into the log file: nothing different from the many other similar pages.

When part of the page is commented out, xelatex hangs no longer at this page, but at the following one. This indicates strongly that the problem has nothing to do with specific page contents but is rather due to some internal operations that set in when a certain amount of input has been read and digested. Xosview indicates that xetex is far from using up my 8GB RAM.

How can I proceed to find out what makes xelatex hang at peculiar, inconspicuous pages?

I am not satisfied with the answer "big images". I want to thoroughly understand why xetex smoothly digests, say, eleven big images, but hangs at #12.

I am not satisfied with the answer "it's sometimes unavoidable". At most, it's unavoidable with the official version of xelatex. But if e.g. the problem has to do with finite stack sizes, why not recompile xelatex with larger stacks.

So this question is really about understanding quite specifically what's going on within xelatex when the above described behavior is observed. Understanding at as deep a level as necessary to think about possible countermeasures (not workarounds).

I freely admit that gaining a few seconds per compilation round may not be worth such effort. Yet again, this is not about practicalities, but about understanding: I am just curious!

Improve this question
11
  • The problem ist at chapter level or below. Outcommenting a previous chapter does not dislocate the point where xetex hangs.
    – Joachim W
    Apr 16, 2015 at 12:33
  • 3
    Takes me up to four seconds to compile a one-page document. You should be lucky. ;-)
    – Johannes_B
    Apr 16, 2015 at 12:57
  • 2
    @Johannes_B: Not helpful. We all know that Knuth had to wait hours when he first compiled the full TeX book. Working habits have changed since then. Believe me, I would not post this question if the delay, short as it may appear, but experienced three times per compilation/bibliography/indexing round and many many times per day, was not annoying. Besides, isn't it also just interesting to learn a bit better how TeX works and why it hangs?
    – Joachim W
    Apr 17, 2015 at 8:19
  • 1
    I am aware that my comment wasn't helpful at all. That's why i placed the smiley. On the other hand, i cannot say something about the issue at hand. Can you reproduce the behaviour on another machine? Is the hanging point the same? Does it work with the xelatex TeX Live/MikTeX is running? Is there any difference with the xelatex version in the last version of your distribution?
    – Johannes_B
    Apr 17, 2015 at 17:48
  • 1
    If you use the draft option, does it still hang on that same page?
    – jon
    Apr 22, 2015 at 17:52

1 Answer 1

Reset to default
6
+25

The biggest culprit (seems to me) would be a large (file size) image, such as a graph with way too many data points or a bitmap with much higher resolution than you need. (I have a friend back in the day generate a Matlab graph of a several second signal from raw data sampled at 40 kHz; the resulting EPS was hundreds of kilobytes and caused similar problems.)

The slowdown might not happen at the exact point you come across the file in the compilation, because XeTeX (usually) runs xdvipdfmx in a parallel thread. Try compiling the document first with xelatex -no-pdf and see if the slowdown still happens. (Then try xdvipdfmx to generate the output and see what happens with that one, too.)

Improve this answer
7
  • 1
    The time command tells me: xelatex takes 6.8s, xelatex -no-pdf 3.4s, xdvipdfmx 4.3s. xelatex -no-pdf runs smoothly, whereas xdvipdfmx hangs at peculiar pages.
    – Joachim W
    Apr 26, 2015 at 18:49
  • 1
    In that case it sounds even more likely that the slowdown is caused by the images themselves. Sometimes it's unavoidable—you just need a big/complex image! If so, you could consider swapping in a dummy image or (as mentioned in the comments above) running in [draft] mode to speed things up in the mean time.
    – Will Robertson
    Apr 26, 2015 at 20:47
  • Thanks, Will. See, however, my latest addition to the question. My question is: why is it "unavoidable"? What happens when several big images are read? My question is definitely not about possible workarounds.
    – Joachim W
    Apr 27, 2015 at 9:56
  • @Joachim: If your images are eps, you will obtain good performance by the command xelatex --output-driver="xdvipdfmx -q -I 24" filename.tex. The performance in the first run does not change. You obtain good performance after the 2nd run. Reason: converted images from eps to pdf are saved 24 hours in a temporary directory and used by the option -I 24. In the default case, eps images are converted every time. Try xdvipdfmx --help.
    – Akira Kakuto
    Apr 27, 2015 at 10:39
  • 1
    @JoachimWuttke Just a flying thought: PS/EPS/PDF are programming languages too, of a kind. It may happen that some of your figures are doing heavy computations before displaying anything; a similar thing happened to me with an image that had to compute many many shadings. So, counter question: can you preview your images and take into account `pure rendering time'?
    – Koji
    Apr 29, 2015 at 8:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.