Memory not freed up after closing score
Upon updating to musescore 0.9.6 stable version (r3145) on ubuntu 10.04 lucid, memory usage of musescore is very high compared to previous versions: according to system monitor it starts at 320 MB and gradually increases. After a couple hours system monitor shows mscore.real to be using more than 1GB of RAM, making the software (and the entire system) extremely low, leading to frecuent crashes. My question is: is this normal? Does musescore need such RAM usage or is something wrong?
Thanks on any help.
Comments
Are you opening and closing several large scores?
It looks like the RAM isn't release after you close a score. For me, MuseScore starts at about 36 MB of RAM. If I open a large score (such as the bach-bc demo) RAM jumps up several MB. If I close the score the RAM usage does not drop. When I reopen the same score RAM jumps up again.
I just check with version 0.9.5 and the same thing happens. So the behavior is not new to 0.9.6.
It happens with any score. The amount of RAM used grows if I don´t close and reopen a given file and also grows if I work on a file without closing it at all. The diference between begining at 36 MB (your case) and my own 320 MB is quite big... So I`m guessing that that much usage simply at opening Musescore is not normal.
In my case 0.9.5 was a lot lighter in terms of RAM usage, using the same files. Is a downgrade appropiate in this cases?
What SoundFont are you using? I am using the light-weight TimGM6mb.sf2 that comes with version 0.9.6
I've being using Fluidsynth soundfont. I've changed to TimGM6mb.sf2: result, RAM usage starts at 304MB (with fluid it started at 320) but after one file playback it jumps to 351 MB and keeps growing from then on.
Current 0.9.6 branch on Windows has the same behavior. Moreover, MuseScore is using 30% of my CPU even when I don't use it.
With 0.9.6 stable on Windows Vista, I have the same behavior described by David. I don't have excessive CPU usage.
I made a screencast at http://screenr.com/eOm . I concur this is a critical issue.
r3233 has some improvements. I lower the priority.
Does somebody have tested valgrind on mscore ?
I use valgrind to hunt memory bugs like writing into deallocated areas and using uninitialized variables. Checking for memory leaks had so far only low priority. There are some known small memory leaks which can only be avoided with some expensive book keeping. Something for the next release.
Maybe it's not musescore by itself, but the development software (in conjunction with the upgrade to Lucy)
I'm experiencing similar slowdowns and crashes with another software (personal accounting) "Grisbi".
It's sure that, beginning with Lucy, Mscore isn't the only one to be slow.
On another hand, previously I was accustomed to have to kill mscore.real
I am not sure to agree with the new title of this issue: it changes the meaning of the post. The real problem is that musescore not only does not free memory after closing a score, it also starts very high (300 MB) with no score at all, and keeps increasing RAM usage until the entire system is unusable. In my Lucid installation musescore is the only software with this behavior.
joseielpi, the bug was limited to a series of steps that developers are able to reproduce. Trying to fix bugs without a series of steps to reproduce the problem can often do more damage than good.
Werner mentioned "expensive house cleaning" which may or may not address your particular problem.
I' m sorry, David, you're right, I did not state the steps to reproduce the bug I filed. Steps I can mention to reproduce the bug are:
1) open musescore 0.9.6, r3145, under Ubuntu Lucid Lynx with no file loaded. Mscore.real uses 320 MB of RAM with Fluidsynth sound font, and 301 MB if soundfont is TimGM6mb.sf2.
2) Open any file. RAM usage increases up to 374 MB with Fluidsynth, and 351MB with TimGM6mb.
3) After working (without closing or opening any other file/s) for two hours, RAM usage increases up to 1GB, making the software slow (1 GB is my system limit).
I hope I was clear this time, (please don't get me wrong, I'm not an English speaker, I may be expressing my thoughts incorrectly), that the problem starts upon opening the software, not when closing a score.
Thanks a lot.
I started MuseScore branch (0.9.6.1) on Ubuntu 10.04. It starts at 33MB with Fluid soundfont and demo score open. In preferences ->I/O only portaudio is checked. While I edit the demo score it grows to 70MB. So I can't reproduce your behavior.
Did you modify any preferences? Can you share a screenshot of your I/O preferences?
Attached is a screenshot of I/0 preferences. I have Jack enabled for playback (for some reason I could never get playback without using Jack). Portaudio is not checked. Could that be the problem? In a minute I'll test with the setting you describe and tell you what happens. Thanks.
Upon testing musescore I/O with only portaudio checked, system monitor says mscore.real using up to 440 MB of RAM. That without any score open and just after opening the program. In case it is useful for you, I'll attach screenshots, perhaps I'm missing something... Thanks again.
That's "virtual memory". If you add a column in your process monitor to display the actual memory or use top in command line you'll see the right number and it 's a lot lower.
Yes. You're right!! actual memory IS a lot lower. Around 100 MB. Just to be sure, I send you one more attachment: is that value normal? I'm guessing that, if it is, the gradually slowing performance of the program has to do with something else. If I wasted you're time, I beg your pardon!
Is this still a problem for you?
Are you able to check the nightly builds?
As there has been no further information, I close this.