2

I'm using MiKTeX for around 2 years with a great template for my university (https://github.com/andygrunwald/FOM-LaTeX-Template).

The results are always great but the time it takes for me to compile the document is terrible. I have to wait for ~2:40 minutes until I can open the compiled PDF document. Two colleagues of mine are using the same setup in regards of template and MiKTeX version and in these cases it only takes 20-30 seconds.

I've already checked a lot of threads and websites which have compiling speed as topic but I couldn't find any solution.

I've checked following things: hardware performance while compiling. Hardware status while compiling These stats are looking fine in my opinion and I dont think that the issue is related to my Hardware. (I7-4510U / 8 GB RAM).

  • I've checked, as already stated the MiKTeX settings and couldn't identify anything which could lead to these bad compiling times. The settings are identical to these of my colleagues who are not facing this issue. I've tried to deactive the "Download missing packets on the fly" setting which didn't increase the compiling speed.

  • I've reinstalled the whole application without any change of behavior.

Via following link you'll find the .log file of the compiling procedure. Link to Log-File

Does anyone have an idea how I could solve this issue?

naphaneal
  • 2,614
Axel
  • 21
  • 1
    Your .log file shows at least 8 very large images being included in your document. The first one being abbildungen/Resultate_auswerten1.png. Reducing the file size of these lossy images would speed up your processing I'm sure. – Werner Nov 23 '17 at 17:12
  • 1
    Hey Werner, thanks a lot for your fast reply. I've removed all these images (which I unfortunately need in this size) and took the time for the project to compile. It still takes 2:18 minutes which is, by comparison to my two colleagues, still really long. Any further hints? – Axel Nov 23 '17 at 17:20
  • how do you compile the document? Do you use the .bat file provided (from the github link)? – Guido Nov 23 '17 at 18:05
  • 1
    You could try to update (with the update manager (admin) and user). There was a bottleneck: https://github.com/MiKTeX/miktex/issues/22. And compile on the terminal to see where the time is lost. – Ulrike Fischer Nov 23 '17 at 18:09
  • Hey Guido, sorry for not mentioning it. Yes, I use the provided .bat – Axel Nov 23 '17 at 18:09
  • 1
    Well the bat compiles three times and calls makeindex and biber, so is naturally quite slow. – Ulrike Fischer Nov 23 '17 at 18:10
  • 1
    Hey Ulrike, I've updated MikTex as you'v suggested but the issue is still the same (while I would say that it's a little bit faster). Regarding the second comment of yours: Yes I'm aware, but as mentioned the compile time is 1/4 of the time I'm facing while using the device of my colleagues (with the exact same software / template). Do you have any further hints? – Axel Nov 23 '17 at 18:34
  • Use a process monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) to find the bottleneck. – Ulrike Fischer Nov 23 '17 at 18:56
  • Are you sure the two machines really have the exact same version of all programmes and packages? Biber 2.8 for example is quite a bit slower than 2.7 if you have many names in your .bib file (part of that should be fixed in 2.9). – moewe Nov 23 '17 at 19:29
  • @Ulrike: I'll try it. At moewe: I'm using this template for 2 years and thus always copied the .bib files to my other projects. So this could be the reason, but my colleagues are working with the exact same files. – Axel Nov 23 '17 at 19:39
  • As I mentioned above, you can only compare the execution times if you can be sure that your colleagues not only use the same files, but also the same versions of all executables (Biber, pdfLaTeX, ...) and packages (biblatex, ...). Did you also check that? – moewe Nov 23 '17 at 20:39
  • Hey moewe, I've just checked the version together with one of my colleagues and we're using the same versions. – Axel Nov 24 '17 at 06:06
  • Mhhh, if you and your colleague have the exact same versions of all files, the same set-up and test with the same documents and there still is a significant difference the only conclusion can be that your PC is significantly slower than your colleague's. If that is not the case, there must be a difference. Ideally you would find that difference. I'd have said that the most likely difference is a version difference if a difference between test files is ruled out. But it could well be something not TeX related. – moewe Nov 24 '17 at 06:34
  • @alex are you sure that your colleagues use the same bat file. In the vast majority of cases, it is totally useless to call biber (to update the bibliography and citations) and to run latex 3 times. Actually, even with changes in the bibliography, in the vast majority of cases, you have to run latex just twice (the bbl file is loaded at the beginning of the run and not at the end). If you run latex once and you do not run biber every, then this takes about 1/4 of the total time (and often there will be no differences). This is compatible with your time and the times of your colleagues – Guido Nov 24 '17 at 07:10
  • @Guido: Yeah, we're using the exact same bat file (which is provided via the template). Thanks for the tip: Which line should I delete from the bat file for these changes to take place? pdflatex thesis_main.tex makeindex thesis_main.nlo -s nomencl.ist -o thesis_main.nls biber thesis_main pdflatex thesis_main.tex pdflatex thesis_main.tex thesis_main.pdf If I understood it correctly I would keep following lines: pdflatex thesis_main.tex makeindex thesis_main.nlo -s nomencl.ist -o thesis_main.nls thesis_main.pdf - correct? – Axel Nov 24 '17 at 09:51
  • You can keep pdflatex thesis_main.tex – Guido Nov 24 '17 at 10:47
  • @Guido: Thanks a lot for the tip. An compiling procedure now takes round about 37 seconds which is an hugh improvement in my opinion. Again thanks for the workaround! :) – Axel Nov 24 '17 at 15:36
  • @UlrikeFischer: Do you have any guides how to identify bottlenecks via procmon? I've never worked with this application and I'm unsure what the easiest way would be. – Axel Nov 24 '17 at 15:37
  • @UlrikeFischer I too suffer the same slow issue, but Your valuable suggestion helps m a lot....Thanks.... – MadyYuvi Jan 24 '21 at 12:40

0 Answers0