Óscar Fuentes writes: > Joseph Mingrone writes: >> Óscar Fuentes writes: >>> Joseph Mingrone writes: >>>> I am seeing even more aggressive memory usage with recent master branch >>>> commits (at least I think this only started in the last month or so). >>>> Here is a screenshot that shows over 3 GB of >>>> RSS. https://ftfl.ca/misc/emacs_memory.png >>>> This was running commit 06726f6 from today on 12.0-RELEASE-p8. I run >>>> Gnus, erc, look at an occasional PDF and edit text. I haven't visited >>>> any extremely large buffers recently. Garbage collection is happening, >>>> but it does not seem to help. But, when I call `garbage-collect' >>>> manually there will be a long pause if I haven't called it recently, >>>> then the memory will usually go down to something between 100 and 400 >>>> MB. >>> Do the garbage collection, take note of the used memory, visit one of >>> those PDF files (preferably one with large, complex & colorful images) >>> move around for several pages and see if emacs' memory usage grows. >> It went from 440 to about 500 MB. This was a book with 1200 >> pages and the PDF was about 3 MB. > How many pages of those 1200 you viewed? Do you use PDF-Tools or Doc > View? If you execute `garbage-collect' does the memory go down? > I'm asking all this because one of the possibilities is a leak on the > image handling code. I just tried it again and held down 'n' to visit all pages and the memory stayed under 500 MB. I am using pdf-tools v0.90. I also just tried with https://file-examples.com/wp-content/uploads/2017/10/file-example_PDF_1MB.pdf and the memory stayed under 400 MB. I'm somewhat confident that I encountered memory issues in an Emacs instance without visiting a PDF file.