The multi-part issue is due to the fact that it is technically still part of a “project” . To be able to use multi-part you should go to Tools->Project and uncheck use as master.
Thanks for the tip on the bibliography. I’ll look into it. For now I just copy paste the keys from Zotero (that I use to manage the bibliography)
I’ve just tried to reproduce the slowness problems with ubth.tm. I do not notice any permanent changes after opening and closing the preamble. After coming back from the preamble view indeed it seems that typing is slower but if I press some backspace then type typing speed seems back to normal.
With the itemise, indeed it seems that it is a bit slower than an empty document. Maybe it takes up to a second to create a new item. I would not say it slows to a crawl. Unfortunately slowness issue are a bit tricky to establish, unless they are flagrant. Can you create a small test case to make your point? You say that it happens also for small documents. We need a way to reproduce the bug if we want to have a chance to fix it.
I tried to edit the formula at the end of the Prop 3.4 and I do not notice any slowdown.
Also, this thread contain many different observations. It is not obvious they are all related. It would be better to address each single observation in a different thread. Or better file a bug report and then refer here to add some more context and open discussion. Joris is not in the forum, he only looks at the bug reports.
I’m supposed to know it but I realise I don’t 
: how do you show the timings?
Thanks for the follow up. Timing is displayed in the console after selecting: “Menu->Debug->Bench”
I’ve noticed slowness on my end and mentioned it here a couple of time, but it seems to have been overlooked.
Dear @hamorabi, could you try to launch TeXmacs from the console and enable benchmarking as described above. We have a suspicion that that some lag is due not to rendering but to other factors that are NOT captured by the above benchmark. An important question is: do you see a correlation between the slowdowns and the logging displayed in the console?
I think that reports on slowness should be more precise and circostanziate. Is not very useful or helpful to the developers to give “general feelings”. I’ve tried to reproduce some of the situations that @guraltsev mentioned. Here my results (on the current svn on MacOSX)
It is indeed true that itemize inside a theorem seems slower. On my machine I guess it takes a bit less than 1 sec to create a new item. Then editing the itemize has normal speed, until a new line need to be created. It does not seems to depend on the size of the document. I’ve tried @guraltsev file and feeling is the same as a shorter file. But I cannot reproduce this consistently. Now I’ve tried again on a small 15 pages document and creation speed is the same inside and outside a theorem.
I cannot reproduce this. I’ve created a file with 15 pages and edited title and author and there is no slowness. I however can reproduce that editing the title of ubht.tm is indeed very slow. This is an anomalous situation as far as my experience goes. I do not remember it happens with my files. I would have to understand why it is so. For example if I change the document style from amsart to article, editing the title can be done at normal speed and if I go back the sluggishness reappears. So seems to be a problem processing the macros in amsart. Worth of deeper investigation.
I cannot reproduce this situation. I followed the istructions and I believe edited the right equation and speed seemed normal (i.e. as for other equations in the document).
Do you get garbage collection times?
I tried it in an empty file and I agree: no slowdown independently of being in or out of an environment.
I tried it in a 35 page paper (not ubht.tm) and slowdown is present in all environments (propositions, theorems, proofs). You can find the paper here:
GNU TeXmacs - Bugs: bug #63631, Slow editing of title and author… [Savannah]
Could you check that you observe the slowdowns?
It seems that the slowdown inside environments is generally present for all operations. For example, in ubht.tm I went halfway through the paper to a proof environment. Granted, some proof environments are multiple pages long but I positioned myself into a proof environment that is 5 lines long. I tried typing in some text inside the proof and immediately outside the proof. Here is the bench
Outside proof:
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 11 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 13 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 11 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 13 ms
Inside proof:
TeXmacs] std-bench, Task 'typeset' took 26 ms
TeXmacs] std-bench, Task 'typeset' took 26 ms
TeXmacs] std-bench, Task 'typeset' took 25 ms
TeXmacs] std-bench, Task 'typeset' took 25 ms
TeXmacs] std-bench, Task 'typeset' took 24 ms
TeXmacs] std-bench, Task 'typeset' took 25 ms
TeXmacs] std-bench, Task 'typeset' took 24 ms
TeXmacs] std-bench, Task 'typeset' took 37 ms
Note that this happens even when there is no reflow happening (either last line of proof or last characters of a partially filled line.
This surely is a particularly big deal, but do you think there is some optimization to be done in changing the environment rendering logic?
I cannot reproduce this. I’ve created a file with 15 pages and edited title and author and there is no slowness. I however can reproduce that editing the title of
ubht.tmis indeed very slow. This is an anomalous situation as far as my experience goes. I do not remember it happens with my files. I would have to understand why it is so. For example if I change the document style fromamsarttoarticle, editing the title can be done at normal speed and if I go back the sluggishness reappears. So seems to be a problem processing the macros inamsart. Worth of deeper investigation.
Yes, I tried with another paper I have written and using the article style instead of amsart does help a lot. It is a bit slower but compatible with the idea that you are rendering a title that has non-trivial spacing.
Now that it seems that this is reproducible for me under windows and under WSL I have filed a bug report. I have also attached two files where this can be observed:
GNU TeXmacs - Bugs: bug #63631, Slow editing of title and author… [Savannah]
Thank you for helping to debug this.
I cannot reproduce this situation. I followed the instructions and I believe edited the right equation and speed seemed normal (i.e. as for other equations in the document).
Now I try and it it is by no means as bad as it was before. You can even see it from the std-bench. Currently, at worst I get 40ms and mostly less than 25s. This is noticeable but it does not distract from working on the actual contents.
The lag I reported before:
TeXmacs] std-bench, Task 'typeset' took 96 ms
was almost a dealbreaker. I honestly am completely confused by what is going on. Maybe the snapshot version running on WSL just works better?
I cannot reproduce this. I’m at Lemma 7.5 of utbh.tm and typing single letters without reflow before the lemma I got
TeXmacs] std-bench, Task 'typeset' took 16 ms
TeXmacs] std-bench, Task 'typeset' took 13 ms
TeXmacs] std-bench, Task 'typeset' took 16 ms
TeXmacs] std-bench, Task 'typeset' took 10 ms
TeXmacs] std-bench, Task 'typeset' took 10 ms
TeXmacs] std-bench, Task 'typeset' took 9 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
typing in the Lemma environement (same conditions)
TeXmacs] std-bench, Task 'typeset' took 16 ms
TeXmacs] std-bench, Task 'typeset' took 10 ms
TeXmacs] std-bench, Task 'typeset' took 16 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 15 ms
TeXmacs] std-bench, Task 'typeset' took 9 ms
TeXmacs] std-bench, Task 'typeset' took 14 ms
TeXmacs] std-bench, Task 'typeset' took 8 ms
TeXmacs] std-bench, Task 'typeset' took 9 ms
TeXmacs] std-bench, Task 'typeset' took 6 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 13 ms
TeXmacs] std-bench, Task 'typeset' took 14 ms
while typing in the proof
TeXmacs] std-bench, Task 'typeset' took 6 ms
TeXmacs] std-bench, Task 'typeset' took 16 ms
TeXmacs] std-bench, Task 'typeset' took 18 ms
TeXmacs] std-bench, Task 'typeset' took 12 ms
TeXmacs] std-bench, Task 'typeset' took 75 ms
TeXmacs] std-bench, Task 'typeset' took 7 ms
TeXmacs] std-bench, Task 'typeset' took 8 ms
TeXmacs] std-bench, Task 'typeset' took 8 ms
TeXmacs] std-bench, Task 'typeset' took 13 ms
TeXmacs] std-bench, Task 'typeset' took 9 ms
TeXmacs] std-bench, Task 'typeset' took 14 ms
TeXmacs] std-bench, Task 'typeset' took 8 ms
In my experience with TeXmacs I never found systematic situations where the program is slow. There were occasions in which particular constructs in a document would make it slow. I think tables are one of this. Sometimes in beamer presentations a lot of decorations made it a bit slower. But I repeat that this is not common and certainly systematic. If it was the case Joris would have met the same conditions (he also uses TeXmacs for his day to day work) and corrected. So what remains are corner cases which are not experienced by the main developers, e.g. I do not use amsart myself and I do not think Joris do. While the bugs or slowness have to be corrected you should expect that they are causes more likely by some bad interaction of some macros with the typesetting, instead of by some general lack of performance. If it was a general lack of performance it would have been known since long and acknowledge by a large part of the community. Joris uses TeXmacs since ~1999 and myself systematically since ~2010 and more sporadically from ~2006. I think we need to pinpoint some reproducible situations. For example the editing of the title in amsart is a good candidate, since seems very reproducible and maybe allow us to understand what are possible sources of slowdown in the typesetter. It is clearly some macro which requires a lot more computation than necessary. Now one would have to isolate which.
Dear @mgubi and everyone,
Ok, I spent several hours trying to experiment and pinpoint a culprit, and honestly, I am desperate! My setup is as follows. I wrote a small script that sends keystrokes that write Lorem Ipsum… to TeXmacs and tried to observe the behavior on different files and in different situations. The results were completely chaotic. I tried multiple combinations: switching a fixed document between amsart and article, editing inside the proof environment, editing outside the proof environment, and much more. I tried closing and reopening TeXmacs, tried copying and pasting the entire contents of a file from one to another and editing the new one, etc. etc.
None of the result seemed consistent but periodically I would get very significant slowdowns.
I managed to observe the following happening (I will try to record a screencast to show you).
** Slowdowns without std-bench symptoms **
On several occasions I managed to use my script to type “Lorem ipsum…” inside and outside of the theorem environment. I consistently, in both cases got
I had Texmacs open on the left of my screen and the console on the right.
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
TeXmacs] std-bench, Task ‘typeset’ took 14 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 12 ms
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
The typing outside the proof environment was fluid. Inside the proof environment letters were appearing in batches of 10-15 (1 or 2 words) with freezes of 0.5-1 seconds in between. There was NO way to observe this from
TeXmacs] std-bench, Task ‘typeset’ took 11 ms
except that, I think, the lines were just not appearing. It seems that the typesetting was taking 11ms but there was something happening in between that made TeXmacs briefly unresponsive.
** Slowdowns because of references and citations**
I tried typing at the end of this paragraph
The latency was
TeXmacs] std-bench, Task ‘typeset’ took 34 ms
so a bit more than expected. I thought it might be due to the references and citations so I erased all of them. The latency went down to
TeXmacs] std-bench, Task ‘typeset’ took 6 ms
I then retyped all references and citations and the latency went up but only to
TeXmacs] std-bench, Task ‘typeset’ took 10 ms
Clearing the profile
I cleared the profile completely and recreated it fresh. After that I was unable to reproduce any performance issues. However, I have done this in the past. After some time, the performance issues return. Maybe it is a cache issue? This would be plausible since windows might deal differently with FS storage than mac and linux. Maybe that is why I reproduce these issues while others can’t?
** Update **
I managed to reproduce the lag even on a fresh profile, but I cannot reproduce the lags recurrently.
Have you ruled out the scheme garbage collector as being the problem?
Nope, I would not know how to do that.
I recorded my experiments. It seems that the issue is not the typesetting, per se, but it is something deeper. The recorded experiments are done with a clean $TEXMACS dir with no configurations. The file is this one: https://savannah.gnu.org/bugs/download.php?file_id=54198 that is attached to this bug
GNU TeXmacs - Bugs: bug #63631, Slow editing of title and author… [Savannah]
I have written a script that sends keystrokes at around 21 keystrokes per second, that is a keystroke every 45ms and types up a filler text.
I experimented with:
here are the videos:
Texmacs fresh profile outside environment good performance
Texmacs fresh profile inside environment good performance
Texmacs normal profile inside environment bad performance
Please note how in the text appears in batches in the “bad performance” video. Note that the computer is still typing at constant speed. Also, no indication of anything “wrong” is registered by the benchmark.
I agree that we need to pinpoint a reproducible situation. I spent most of today trying to, but the behavior is sneaky! I am happy that in the experience of multiple people these issues do not occur. Maybe it is because they do not use Windows, Maybe because I often start by importing my files from LaTeX drafts, maybe for some other reason… I do not know.
I often clear my whole $TEXMACS dir and at times it seems to help a bit, but that maybe just placebo. Let me start again with a fresh clean profile. If the sluggishness above reappears, I will record an follow up.
Even with these issues I use TeXmacs regularly, and I have been for more than a year (of course, nothing compared to your expertise). Unfortunately, for me the experience was often a compromise between the great ability to write math naturally and the low responsiveness of the editor. I really hope we can get to the bottom of this (or at least document the things that one should not do!)
Please let me know if you have any ideas on how to continue debugging.
P.S. I was trying to look through my preferences.scm and I see that it gets populated naturally (without me doing any configuration) by lines that look like this:
(“shift-65” “A”)
(“shift-68” “D”)
(“shift-69” “E”)
(“shift-76” “L”)
(“shift-82” “R”)
(“shift-83” “S”)
(“shift-84” “T”)
(“shift-85” “U”)
(“shift-88” “X”)
(“shift-95” “_”)
Do you know what this means?
Would in this case the slow-down depend on something that happens after typesetting?
Besides this, how do you get the debugging output under Windows? Maybe you explained it but I lost it.
@darcy @pjoyez @jeroen some of you can reproduce these problems? or have experienced similar issues?
@guraltsev please don’t get crazy about it. This is the normal state of affairs when dealing with some bugs. A big program is a complex system and its current state is affected by many things, so one has to systematically try to vary some of the conditions to get a sense of what could be the origin of the problem. E.g. what happens if you use article instead of amsart? Or what happens if you remove the rest of the paper and make it shorter. One should try to remove progressively more and more content to see what is going on. As I remarked above I expect the slowness could be originated by a series of conditions which have not been happening often, otherwise it would have been detected sooner. That happened to you in your first use of TeXmacs is somehow random, we just have to understand what is going on and see if we can fix it. Also removing all the $TEXMACS_HOME_PATH is a bit radical. I do not think fonts are important in this problem, so you could try to remove one of the other subdirectories to see what happens.
The benchmarks I run are through WSL (linux under windows). You are right that the windows one does not display debug information.
You are right. I got a bit carried away yesterday. Now that I have a way to debug slowness I’ll report more in detail when I catch some degraded performance.
I think one can still run the TeXmacs executable from the command line in a Windows terminal. This should allow to see the output.
Under windows nothing is displayed in the command line. I think I reported this some time ago and it was confirmed.
