textext / textext

Re-editable LaTeX/ typst graphics for Inkscape
https://textext.github.io/textext/
BSD 3-Clause "New" or "Revised" License
841 stars 38 forks source link

Memory leak when opening/closing the Latex editor #327

Closed AdelKS closed 2 years ago

AdelKS commented 2 years ago

Hello,

While working on my presentation on Inkscape (I use it instead of Libreoffice Impress as it is way more flexible), the document became big enough and opening/closing the Latex editor is slow and causes memory leaks: the RAM used by inkscape keeps on increasing and ends up filling nearly my entire RAM.

This issue doesn't happen with a fresh and empty Inkscape document. So mine is probably faulty again, but I have no idea what's wrong, would love to get feedback on this.

Here's the document that causes leaks, I couldn't attach it here...

Thanks!

jcwinkler commented 2 years ago

Unfortunately, I cannot reproduce the problem on my machine using your file. Latex code is processed properly and inserted into the document.

Of course, processing time is quite large. Your svg is > 50MB and you have to know that the Inkscape extension API passes the full svg document to its extensions which then insert their stuff and passing the code back to Inkscape. So alot of parsing is done in this process chain.

Maybe, as a workaorund, you can just use a single svg file for each Impress slide? That's how I do it when creating complicated graphics for WYSIWIG presenation programs.

BTW: You are using Inkscape 1.1 and TexText 1.6.1? On which platform?

AdelKS commented 2 years ago

Thank you for your feedback!

Unfortunately, I cannot reproduce the problem on my machine using your file. Latex code is processed properly and inserted into the document.

The code is processed properly for me too, it's just this issue of inkscape/python not freeing the RAM textext uses for processing. Since you cannot reproduce it, it's probably a bug in my inkscape or python, I will recompile them to see.

Maybe, as a workaorund, you can just use a single svg file for each Impress slide?

It's way more comfortable for me to have a single file and processing time doesn't bother me. I do not use Impress at all, I use Sozi to have a slideshow: it uses the single SVG file directly to embed it on a scripted HTML file that can be run locally on any browser

Thanks!

jcwinkler commented 2 years ago

TexText does not explicitely allocate memory. It just uses pure Python so everything should be cleaned up after the extension is closed. I will have a closer look onto this issue. Maybe there is also an issue with Inkscape's extension subsystem.

Does it also occur with pre-compiled Python and Inkscape binaries?

AdelKS commented 2 years ago

Alright I just tested on Arch (my memory leak issue happening on Gentoo) and I cannot reproduce the memory leak: Inkscape indeed initially allocates more memory but it doesn't keep on growing indefinitely.

The only difference between the two distros I can think of is that everything is built on -O3 -march=native on my Gentoo whereas Arch simply builds with -O2 without enabling any extra instructions than x86_64. I will retry with Inkscape built with only -O2.

I will close this issue when I figure out the cause of this.

Thanks!

jcwinkler commented 2 years ago

Maybe the Inkscape developers can help you, too. The easiest way is to contact them in the Inkscape rocket chat. #team_devel is the right room to talk there.

AdelKS commented 2 years ago

Awesome thanks!

AdelKS commented 2 years ago

I did not take the time to get to the bottom of all this as my PhD defense is in two days, but the memory leak also happens with Inkscape of Arch. So in the end it has nothing to do with self-compiling anything.

When I am done, I will take the time to open proper bug reports and help hunt down this issue. Thanks!

PS: Editing equations is indeed painfully slow, was it the case with Inkscape 0.92, beacause I don't remember it to be that slow at that moment ? Or they did an API change in 1.0 ? What is currently offered is rather powerful as extensions can literally do anything, but the downside is something like my use case x)

jcwinkler commented 2 years ago

Hi @AdelKS I hope you successfully defended your thesis.

Meanwhile I did some further checks and I confirm that also on Windows there is an issue with the document you provided:

grafik

We can clearly see that the allocated memory increases from step to step and is not freed after closing the document. Question is if this is really a bug. May be it is related to the undo history? But undoing some of the changes do not free any memory.

PS: Editing equations is indeed painfully slow

You have to know the following: When invoking an Inkscape extension the complete svg code is passed to the extension by Inkscape's extension subsystem. The extension then needs to crawl throught the document to find the node you selected if you intend to edit an existing equation. After the LaTeX code is compiled the node is inserted into the svg-xml-structure and then the complete document is passed back to Inkscape by the extension subsystem. So in case of the document you provided there is quite a lot of data moved fore and back.

Next step is to check if the memory leak effect occurs also if the extension does nothing. I.e. I will modify the extension such that the xml document is just passed to TexText and then passed back to Inkscape without doing anything. If the effect is still present in this case we need to contact the Inkscape developers.

AdelKS commented 2 years ago

Hello @jcwinkler !

My PhD defense went amazingly well. I am happy to have invested this huge amount of work while making a beautiful and pedagogic inkscape presentation. Inkscape was very painful and made me lose lots of time, so now it's time to fix all this.

I have an idea about this memory leak: in the 0.92 or 0.91 version that I was using in a year or two ago, they had a huge issue with text fields : editing them was painfully slow and made Inkscape crash frequently. They seem to be working on this but it's still not entirely figured out. While working on my presentation, Inkscape was crashing every 3-4 minutes while I was editing text fields. And sometimes writing multi-line text fields fails and the next line writes over the previous line (no newline is made).

Since I have been recycling elements from my past presentations that used the then broken Inkscape 0.92.x, I think maybe I am carrying buggy SVG XML code or something. But in any case, this is a bug within Inkscape as I believe it needs to sanity check the XML, especially buggy XML it used to produce.

I will modify the extension such that the xml document is just passed to TexText and then passed back to Inkscape without doing anything. If the effect is still present in this case we need to contact the Inkscape developers.

If I press cancel and not do anything, the used memory does indeed get worse. But you seem to be saying that textext does something anyway in that case. Yes ! please keep me updated when you implement the change. I will try to narrow down the buggy document to fewer elements.

You have to know the following: When invoking an Inkscape extension the complete svg code is passed to the extension by Inkscape's extension subsystem. The extension then needs to crawl throught the document to find the node you selected if you intend to edit an existing equation. After the LaTeX code is compiled the node is inserted into the svg-xml-structure and then the complete document is passed back to Inkscape by the extension subsystem. So in case of the document you provided there is quite a lot of data moved fore and back.

Yea I understood that after you explained it to me further up. I took some time before realizing that I am incredibly stupid then made editing equations more efficient: I opened a blank Inkscape document in which I was copying the equation I wanted to edit from the main document, edit it, then copy it back in the document. And voila! Super fast equation edition xD. Maybe you can implement something similar with textext ?

AdelKS commented 2 years ago

Okay I can reproduce this with this cut down version of the SVG document (change the extension to .svg):

memory_leak_v2.svg.txt

Here's a video demonstrating the leak (change the extension to .mkv):

Memory leak demo.mkv.txt

Interesting finds: on Gentoo the memory leak is way bigger per Textext edition than in Arch. I believe it comes from the different flags that are used to compile Inkscape and Python. But maybe it comes from the default settings of Inkscape, like how many "Undos" can be done ? I did not touch that except the keyboard shortcut for Textext in both Arch and Gentoo

Question is if this is really a bug. May be it is related to the undo history? But undoing some of the changes do not free any memory.

I think it really is, memory should be freed at a given point. I have reached many times OOM and had to manually turn off my computer...