Normally memory should be given back. Some memory may hang on for caching purposes, to make things run more smoothly, but that ideally should only be limited.
We did fix some memory leaks in the previous release, so you should see some improvement. Though that probably should be modest, they weren’t really big ones. Currently, I cannot see any memory leaks in the analyzing tools. (Though that does not catch all memory leaks, though it should catch memory leaks from Cocoa programming). Though I do get the impression that PDFKit in 10.11 does run up memory a lot. I don’t know if that is a leak or excessive caching. I can’t find where it is, and if it is in PDFKit it certainly is nothing we can do about. And seeing it in Preview also points to problems in PDFKit. Christiaan > On Sep 1, 2016, at 14:30, José Miguel Figueroa-O'Farrill > <[email protected]> wrote: > > I still experience the same problem. Long gone are the days where I could > just keep Skim running for days on end. I now have gotten used to having to > quit it periodically to get the memory back. So my guess is that Apple has > not addressed the problem. > > José > > > >> On 1 Sep 2016, at 13:23, Jan David Hauck <[email protected]> wrote: >> >> I have to come back again to the thread from earlier this year about the >> likely El Capitan PDFKit Memory leak. >> >> It seems that something has changed from the previously reported behavior, >> it now seems that some memory is given back to the system, but still not all. >> >> I had 30 pdfs open and it said it was using 23 GB of RAM (total memory). >> Upon closing 8 of them it went down to 20 GB. >> After closing Skim and restoring the session these 22 now newly opened pdfs >> only needed about 2 GB. >> But after keeping Skim open for a while, reading through pdfs, annotating >> etc. it slowly kept growing again, now it's back to 7 GB, roughly 24 hours >> later. >> Shouldn't it give back memory automatically even when not closing pdfs? >> >> I'm afraid, I now far too little about how this works or should work, so >> maybe it's just that I open too many pdfs or that my pdfs are too big. But >> I'm wondering if others can also still report odd behavior, and if there >> might still be something wrong with PDFKit? >> Did Apple ever respond to any of the bug reports? >> >> >> >> PS: Same behavior in Preview. >> >> >> >> On Tue, Jan 5, 2016 at 4:44 PM, Christiaan Hofman <[email protected]> wrote: >>> On Dec 20, 2015, at 23:18, José Miguel Figueroa-O'Farrill >>> <[email protected]> wrote: >>> >>> Hi, >>> >>> I’m running Skim Version 1.4.16 (90) on Mac OS X Version 10.11.2 (15C50). >>> >>> I wonder whether anyone else has seen this behaviour: Skim is using a huge >>> amount of RAM. According to Activity Monitor, Skim is using >>> >>> Skim | 13.42 GB | 7.49 GB | 11 | 283 >>> >>> in the notation >>> >>> App | Memory | Compressed Memory | Threads | Ports >>> >>> In fact, the system ran out of application memory yesterday and I think it >>> was due to Skim. (It was one of two apps which were not responding.) >>> >>> I’ve gone back to 1.4.15 (89) for now. >>> >>> Cheers, >>> José >>> >> >> BTW, it does seem like more people are seeing this. Moreover, it is also >> seen in Preview. That means, as I would expect if it’s really there, that >> it’s a bug in PDFKit in ElCap (one of many serious bugs, unfortunately). >> I’ve reported this to Apple, but given how (non) responsive they are on the >> even more obvious and visible (and simpler to fix!) bugs, I don’t expect >> them to fix this before 10.12. >> >> Christiaan >> ------------------------------------------------------------------------------ _______________________________________________ Skim-app-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/skim-app-users
