Skip to content
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

In master on Windows, memory usage increases linearly over time for both MS Basic and Muse Sounds, at different rates #22721

Open
metasekk opened this issue May 8, 2024 · 0 comments
Assignees
Labels
P2 Priority: Medium playback General playback issue

Comments

@metasekk
Copy link

metasekk commented May 8, 2024

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

  1. For Windows users, open the task manager.
  2. 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).
  3. 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 :

Average_MS4_Memory_for_MuseSounds_3_studies

  • 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 :

Average_MS4_Memory_for_MSBasic_3_studies

  • 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)

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.

@muse-bot muse-bot added the playback General playback issue label May 8, 2024
@bkunda bkunda added the P2 Priority: Medium label May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Priority: Medium playback General playback issue
Projects
Status: Issues to fix
Development

No branches or pull requests

4 participants