You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Closing and reopening a score leads to a gradual (affine) increase in the RAM memory used by MuseScore, with very rapid growth for Muse Sounds, as though the sound banks loaded in memory were never released, but instead, stacked.
Steps to reproduce
For Windows users, open the task manager.
Open this score for Muse Sounds (empty score with Muse Sounds as the default profile) or this one for MS Basic (same score with MS Basic as the default profile).
Close it and reopen it several times, and compare the memory of the task "MuseScore4.exe" after each cycle.
I provide a (tedious) video here, demonstrating this process step by step (beware: I couldn't change the language of the task manager, therefore it is in French; memory is the column entitled "Mémoire" - a quite transparent one). The results are rendered quantitative below.
Screenshots/Screen recordings
I conducted two studies of repeated closing/reopening cycles (three times each), for MS Basic and MuseSounds respectively. Here are my findings:
For Muse Sounds :
The figures are highly reproducible : the standard deviation for each figure is <5 Mo.
It increases monotonically : no drop nor jump occured in the three cases.
For MS Basic :
The figures are also highly reproducible on my side : the maximum standard deviation for each figure is <20 Mo.
A very surprising "jump" from ~350 Mo to ~800 Mo can be seen for MS Basic. It was observed in the three studies, and every time between 5 and 10 re-opening cycles. In 1 case (over 3), there was another drop between 15-20 reopenings, where the memory went back to ~400 Mo.
I don't know what it reveals about the way the memory allocation/deallocation is implemented, but based on this, I suspect it is different between MS Basic and Muse Sounds, which was quite surprising to me. For MS Basic, the jumps and drops in memory might indicate something dubious in the handling of it.
MuseScore Version
The results above were obtained in 4.4 master (tested on MuseScoreNightly-241290306-master-48c7fdd-x86_64), but the issue occurs identically in 4.3
Already occurs in 4.2.1 and 4.1.0, but at a much slower growth rate than in 4.4 and 4.3.
Occurs similarly with all versions of MuseSampler (tested with MuseSampler 0.6.3, 0.6.1, 0.5.1, 0.3.2)
NB1: I could only conduct this experiment on Windows 10.
NB2: On "real" large scores, the amount of RAM required by one score (when first opened) can climb up to 7 Go, making this issue immediately critical when trying to reopen the score only once.
Issue type
General playback bug
Bug description
Closing and reopening a score leads to a gradual (affine) increase in the RAM memory used by MuseScore, with very rapid growth for Muse Sounds, as though the sound banks loaded in memory were never released, but instead, stacked.
Steps to reproduce
I provide a (tedious) video here, demonstrating this process step by step (beware: I couldn't change the language of the task manager, therefore it is in French; memory is the column entitled "Mémoire" - a quite transparent one). The results are rendered quantitative below.
Screenshots/Screen recordings
I conducted two studies of repeated closing/reopening cycles (three times each), for MS Basic and MuseSounds respectively. Here are my findings:
For Muse Sounds :
For MS Basic :
I don't know what it reveals about the way the memory allocation/deallocation is implemented, but based on this, I suspect it is different between MS Basic and Muse Sounds, which was quite surprising to me. For MS Basic, the jumps and drops in memory might indicate something dubious in the handling of it.
MuseScore Version
The results above were obtained in 4.4 master (tested on MuseScoreNightly-241290306-master-48c7fdd-x86_64), but the issue occurs identically in 4.3
Already occurs in 4.2.1 and 4.1.0, but at a much slower growth rate than in 4.4 and 4.3.
Occurs similarly with all versions of MuseSampler (tested with MuseSampler 0.6.3, 0.6.1, 0.5.1, 0.3.2)
Regression
I don't know
Operating system
Win10 (22H2); RAM: 16Go; CPU: Intel Core i5-9300H (2.40GHz)
Additional context
NB1: I could only conduct this experiment on Windows 10.
NB2: On "real" large scores, the amount of RAM required by one score (when first opened) can climb up to 7 Go, making this issue immediately critical when trying to reopen the score only once.
Somewhat related to #22094, #20889 and possibly #22710; part of #23112.
The text was updated successfully, but these errors were encountered: