New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
latex got slower with updates #782
Comments
you should test without loading all these files to identify how much the changes in latex itself (which contains now more code, more hooks and the shipout has changed too) and how much e.g. the file loading in miktex contribute to the slow down. Side remark: you should switch to utf8, latin1 is really no longer up-to-date (and not supported everywhere). |
You mean to skip all the packages and do just this:
? With that I get more or less something like: In MiKTeX 21.3 (shows LaTeX2e <2020-10-01> patch level 4 / L3 programming layer <2021-02-18> in log): Not sure if this means miktex or latex is a problem or both? It's still proportionally around 2 times slower. |
If I use the
This would explain the performance degradation. @jjachimowicz: can you repeat your test and then compare the |
Hi @edocevoli, indeed the amount INPUTs grows significantly. In 20.6.29 it was all much shorter
In 20.6.29 there are 2 entries for "INPUT C:\Program Files\MiKTeX\tex\latex\base\book.cls", in 20.12 I get 10 entries like this and in 21.3 I get 11 entries. Same increase for l3backend-dvips.def. For bk10.clo it grows from 2 entries to 4. I've attached the output myfile.20.6.29.fls.txt |
@edocevoli I saw that and we are looking at it. |
Is this still an issue? If so, we can reopen this ticket. But I think the performance issue has been "fixed" in the course of development. |
Hi @edocevoli, I have now pulled all the possible updates for my Windows MiKTeX version and the issue is still there. I see some improvement in my real life documents, but it's not near the speed of MiKTeX 20.6.29. Originally I had generation times around 20s, then 55s when reporting this ticket and now I have something like 45s. Moreover the amount of |
The number of
But it cannot be avoided by MiKTeX. Can I assume you used the same LaTeX version when you ran the tests? |
I come to the conclusion that this is not a MiKTeX-specific issue. Comparing MiKTeX and TeX Live execution times by running
|
@edocevoli have you tried comparing on Windows as I do? I tried comparing MiKTeX vs Tex Live on Windows and I get significantly different results (tried on few simple documents):
I also added the --recorder and both produce this big amount of INPUT for book.cls and others. So it's not the INPUT. |
Yes, on Windows. I used a Cygwin bash shell. |
After updating MiKTeX our existing document generation got around 2 times slower than before. After a lot of trials with installation of older versions, it seems that that the generation is fine in MiKTeX 20.6.29, but gets slower in of the version or versions after. I managed to create a fairly simple .tex file for reproduction (loading more packages than needed to get longer execution times):
If I run this in latex (
latex myfile.tex -time-statistics
) I get the following results:gross execution time: 778 ms
user mode: 765 ms, kernel mode: 140 ms, total: 905
gross execution time: 633 ms
user mode: 593 ms, kernel mode: 93 ms, total: 686
gross execution time: 256 ms
user mode: 296 ms, kernel mode: 93 ms, total: 389
Of course the exact values for each run are not identical +-50ms, but the overall picture is the same: 20.12 is a slightly faster and 20.6.29 is much faster. That's similar to what we see when running our normal .tex files, but in our case the documents are much bigger and the performance impact is more problematic.
The performance difference seems the same also for the
sample2e
, where it gets around 2 times faster when switching from 21.3 (200ms) to 20.6.29 (100ms).With every installation I'm also removing the miktex folders in user's AppData folder. Also tried experimenting with all users vs single user installation, but this doesn't influence the results.
miktex-report.txt
time.21.3.txt
time.20.12.txt
time.20.6.29.txt
The last 2 logs (20.12 and 20.6.29) contain information about not checking updates, but in that case it's justified. I rely on what is in the package to get older (faster) code. If I run the updates I get upgraded to 21.3 and get the exact same (slower) execution time.
The text was updated successfully, but these errors were encountered: