-
-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maccy After being used in the background for many times, the memory occupation increases linearly #384
Comments
Device: MacBook Pro 14`2021 I have this same issue; when Maccy starts on my machine, it uses 24.9MB ram. After some time (several days), ram usage goes up to 350-500MB. Clearing the history doesn't reclaim any ram; closing and restarting Maccy does. There's clearly a memory leak going on somewhere. |
The way Maccy uses Core Data could probably be improved to avoid memory bloat - right now every new copy is kept in-memory so if you copy large images (for example) - it can increase over time. I need to see if there is a way to make Core Data work in a different way by offloading unused items from memory. |
Alex thx for this. From the behaviour I've seen on my machine, it appears that references even to deleted items are being retained. The memory usage remains the same even after deleting all items by doing a 'Clear'. |
What's the status of this issue? |
No progress at the moment. |
Is it the same how Microsoft Windows store (Windows+V) clipboard items, via memory? I'm thinking if there should be an option to store locally or via memory. |
Maybe users have set a large history size? And a lot of images copied.(Just random guess) |
It's not the case: I can reproduce with small text entries also. Just wait some time and the memory increase progressively |
it often gets dangerously close to 2gb... |
I've been looking into this issue a few times already and I don't know what can be improved at the moment. Here is a simple video showing that Maccy keeps text/images in memory but offloads at least a portion of it whenever it's closed.
If somebody understands Core Data and ways to lower memory consumption, I'd be happy to implement the recommendations, but I don't know what to do with this. o.mp4 |
@tony-swg Do you copy lots of images or just text? |
yes, both |
After updating my system to Sonoma and Maccy to latest version, with each opening (command shift c) the memory usage increases by around 300kb |
Folks, I get it - there is no need to post screenshots of RAM usage. It would be more helpful if someone would actually suggest ways to reduce the memory overhead or, ideally, send a PR. |
I have no idea what cause this problem. But I suggest you could publish a build with regular relaunch the main program for quick fix. |
I suggest a temporary solution - restart the program every hour using crontab. Open a terminal, enter the command
save changes. It should look like this:
|
For me the RAM usage was ~12 GBs, Quitting didn't help. So I deleted everything and reinstalled it. |
I appreciate this software and hope this issue can be resolved promptly. As this software has been developed and maintained by the author for a long term, very few people are familiar with this project besides the author. While waiting for contributions from the open source community may not be the most effective solution for a quick fix, I also hold hope that a kind soul might come forward to address this issue. |
Is it tried to free some history from memory (and save it to disk) when the memory usage exceed a limit? If not, I think this can be a temporary solution. And maybe it's possible to ask Microsoft that how |
Folks, please share how things work for you on Maccy 2.0+ |
A little more robust workaround than #384 (comment) that avoids killing Maccy while currently open: https://gist.github.com/kra-mo/e404d594d3d1c18e4db37013c9bec694 Just put it in |
Operating environment
Describe the problem
After running Maccy for a long time and using it for many times, the memory occupation of the application will gradually increase (it seems to grow linearly and there is no sign of release). It can be recovered after restarting the application.
I hope the author can fix this problem, thank you.
The text was updated successfully, but these errors were encountered: