search

izuzak / atom-pdf-view

Support for viewing PDF files in Atom.
https://atom.io/packages/pdf-view
MIT License
108 stars 30 forks source link

excessive memory usage #225

Open quantenschaum opened 5 years ago

quantenschaum commented 5 years ago

pdf-view 0.71.0, atom 1.39.1 x64, Ubuntu 19.04

When opening and closing several PDFs atom uses more and more memory and does never free it up. I'm talking about GBs!

pdf-view-memory

Note the memory usage dropping when closing atom.

Petersoj commented 5 years ago

I am experiencing the same issue. After lots of rebuilding with Atom LaTex plugin and reloading the PDF automatically, I found out that Atom was using over 8GB worth of memory. Major issue!!!

izuzak commented 5 years ago

Thanks for reporting this, @quantenschaum @Petersoj :bow:

I'm afraid I'm not very familiar with PDFjs (the library this project uses for rendering PDFs) and I also never had the time to investigate these performance issues some folks are having trouble with. Buuuut, @Aerijo opened a neat PR which I just merged #226, and we're hoping this might help with the memory usage.

Could you try updating to the latest version (0.72) of this package, and see if that helped in any way with the memory usage? 🙏

Thanks again!

quantenschaum commented 5 years ago

No, unfortunately it didn't change the behavior at all. Tested with pdf-view 0.72.0

If I open and close the same PDF again and again, each time it is opened, more memory is acquired, but not freed up upon close. ... until it goes :boom:

Aerijo commented 5 years ago

@quantenschaum If you open dev tools and look in the memory tab, does the PDF worker get destroyed? There should be one worker around 40MB for each open PDF.

Aerijo commented 5 years ago

Ah, I see the RAM use still goes up and stays up.

Aerijo commented 5 years ago

@quantenschaum I've published an alternative PDF view package, which uses the default viewer provided by PDFjs. It should not have any lasting memory issues (it also comes with a lot of benefits "for free", like thumbnail view & only loading visible pages).

As for this package, I don't know how much can be done / is worth doing. E.g., I've no idea why it would hold that memory, and it would probably take a lot of time to fully fix. It's possible only an upgrade of the PDFjs version (which is currently 2-3 years behind the current release) will fix it.

In general, this package tries to manage the view itself, so there's a lot of interaction with the core that is difficult to handle properly without investing a lot of time into learning PDFjs. This makes it a big cost to maintain and upgrade PDFjs versions. By using the default viewer in the alternative above, I hope to avoid almost all viewer issues, and only have to worry about integrating it with Atom.

quantenschaum commented 5 years ago

Thank @Aerijo! This does not eat up memory.

Foggalong commented 4 years ago

Can confirm that I'm also having severe memory issues when compiling and recompiling beefy LaTeX documents, O(100) pages. The leak is such an issue that it locks up the computer for up to a couple of minutes after compilation and eventually causes Atom (and on occasion my absolute UNIT of a work laptop) to crash.

I've not been able to reproduce with this with other combination of enabled packages (including compiling LaTeX externally and then viewing using atom-pdf-view), any external pdf viewer, or pdf-view-plus, nor have a been able to see any difference in the rate of crashing between using different version of pdf-view.

@izuzak Is there any scope for having this package switch to the default PDF.js viewer rather than its own custom one? That would be more convenient that using pdf-view-plus since pdf-view specifically is what is referenced by some LaTeX extensions.