Musescore 2.0.3 is Very Slow

• Apr 26, 2016 - 00:21

After downloading Musescore 2.0.3 my longer scores caused the program to slow down. The short ones work fine but I don't understand why the long scores that worked fine in 2.0.2 are slow in 2.0.3.


Comments

A few people seem to be seeing this issue, but so far it's a bit mysterious (to me anyhow). Some report the problem onl shows if the Navigator is open, and also goes away if you resize the Navigator even slightly. Does this hep? If not, can you please post more system details - what OS, how much RAM, etc.

Note that large scores are always slow to work with - always have been. If you have a specific score that seems to be slower even after closing or resizing the Navigator (if it was open to begin with), please attach it so we investigate.

In reply to by Marc Sabatella

I was still having some trouble with the 7-29 nightly build, so I wanted to give some feedback to see if I can help with development.
I have 8GB RAM, a mobile-class Core i7 CPU with integrated Intel graphics. My screen resolution is nearly 4K.
The slow note problem for me is contingent upon how many score tabs I have open. I am not hitting the ceiling of my computer's RAM. With just one open, there is still a bit of latency for me: if I hit the 'up' and 'down' keys simultaneously (to move the note as rapidly as possible in the system), there is about 100-500ms (hard for me to tell, not being trained) of latency. Then the note moves twice as expected. However, I notice no real difference from my 2.0.3 edition with only one score open. With several scores open, it starts taking increasingly more time.
When I select everything on my small score and move it up an octave (which I sometimes really have to do in composition), it actually moved more everything more efficiently on 2.0.3. I recall having issues with that before, which means that is probably also just dependent on the number of score tabs I have open at once.

Another issue I have found, even with having just one score open, is that when resizing and manipulating the score perspective (scrolling and moving and resizing the pages themselves), there is a noticeable amount of lag: the framerate for this change in perspective does not keep up with my screen, and so it looks choppy whenever I go to move or resize things (with a touch screen especially, since using a scroll wheel makes more sense with that distinct graduation to me anyhow, because it has that effect in text documents as well). I think this is related simply because these are two of the most important aspects (for me) of how the program feels while I am using it. It is still having some issues with responsiveness on both note manipulation and page manipulation.
Just panning with the mouse wheel (not zooming or dragging) seems to be smooth enough, and the program cleanly responds right away.

So in summary, I do not notice much of the performance improvements just yet: I would suggest looking into ways of taking input from the keyboard faster somehow: there was still a bit of delay from when I touched both of my arrow keys and when the note moved, as though it were lining up my keystrokes to sit through some sort of buffer. I would avidly appreciate if there were some way to smooth out scrolling and panning and zooming (especially on my dense touchscreen monitor), and if performance could be far enough ahead of resources that having a handful of scores open is no problem.
Please let me know if I can other or more specific information, and also whether I should post comments like this in a different part of the forum next time.

In reply to by Marc Sabatella

Thanks a bunch for this! Wish I knew all I had to do was this (never looked into it before). Kind of a shame, as I love the Navigator in Musescore (and Inspector). Anyways, here's a quick screen capture showing before and after turning off the navigator (doing the same things). *Also, I tried turning it back on and resizing the Nav, but it didn't work*
https://www.youtube.com/watch?v=khcZt1kNJQc

Computer details:
Windows 8.1 Pro 64-bit
Intel i3 3040u @ 1900 MHz (x2)
6 GB RAM

In reply to by mel.lebreuilly

There are two observations I may add to this (using Mac OS Yosemite and MS 2.0.3. Is there a correlation of this problem to the kind of OS people use?):

- Closing all (usually four or fewer) tabs except the one I am working on has not helped me at all contrary to other people's experience.

- This one I have not seen mentioned yet: If I have a score with this problem what seems to happen is that the problem builds on itself: I am proofreading, so all I do is navigate and read and make the occasional correction; the size of the score is practically constant. Yet it gets slower and slower. At the end it is hard to even close the navigator (click view, wait many seconds, the menu finally pops up, click navigator, again many seconds later the checkmark goes away and the navigator eventually closes).

- As soon as the navigator is closed the system is fully back to normal speed (my scores are quite large sometimes, say a ten to fifteen minute string quartet score, but not truly giant such as a symphony movement would be). Only the convenient navigation the navigator provides is missing.

This last point is not unimportant: Without the navigator I have to drag the score with the mouse (or is there another way?) and every so often I inadvertently change a note or a marking when I hit it accidentally with the mouse.

In reply to by Marc Sabatella

I didn't know about the arrow navigation (Apple does not think I need a mouse wheel...). Thanks for pointing this out.

However, navigator is still more handy because you can aim where you are going rather than scroll until you arrive (assuming you make your navigator widow large enough). Especially on larger scores--exactly on those that slow down with the navigator on...

In reply to by azumbrunn

The problem should go away if you adjust the size of the Navigator such that it does not display almost exactly the whole score. So either make it tall enough that the last couple of thumbnails are off the end, or make it short enough that there's a couple of thumbnail's worth of extra space at the end.

Hello everyone. My first post. I have been using Musescore for some years (1.3 on Raspberry Pi2 ) and now 2.0.3 on my purpose built video editing PC, and prior to that my old Sibelius 4! The upgrades to Sibelius became so expensive, I was pleased to discover the excellent Musescore!

I have been having the slowdown problem with a very large piano score for 4 hands. I think the note entry by mouse became unusable at around 420 bars, about 60% of the full score. The full score is about approximately 580 bars of four piano staves. The problem is the huge lags between mouse clicks and registering the note. Indeed it becomes so slow and unstable that the wrong note is often chosen! I solved it by simply breaking the score into roughly two halves. I think the Navigator window may be the culprit as suggested above. I needed it to jump around the sections of music. I will try all the helpful suggestions for the workarounds.

The slow down seems to get exponentially worse. At one moment it is very slightly slower and within a few bars it is progressively getting worse to unusable. This looks like a program data buffer gets nearly full and then everything slows. The buffer must be quite large as in normal use there is never any problem. Perhaps the Navigator window data shares the same "buffer"?

Thank you for a brilliant program. I can live with this minor quibble!

In reply to by [DELETED] 7670311

The slowness that comes with larger scores is, fortunately, already mostly eliminated for MuseScore 3: https://musescore.org/en/user/101731/blog/2016/06/02/developing-musesco… However, none of the improvements apply to note input yet, so that is currently just as slow in the nightly builds as it is in MuseScore 2: #114361: Note input calls doLayout function (relayout entire score) instead of doLayoutRange, resulting in slow response time

In reply to by [DELETED] 7670311

To be clear, the fact that large scores get slow is a known issue with *all* versions of MuseScore (that will be addressed in 3.0). That is because the entire score gets laid out on every edit, with or withiut the Navigator (although to be sure, the Navigator makes it worse, because it means the score must actually be laid out *twice*). This is a totally different issue from what is being discussed here, which is a slowdown that occurs on *all* score - even the smallest - and *only* when the Navigator is displayed, *only* if it is right on the edge of being able to display all pages so it can't quite decide whether or not scroll bars are needed, and *only* in 2.0.3 as far as I know.

Posting this on a few of the "slowness" threads because I am so pleased with the result I just encountered. I was having maddening problems with freezing/hanging/stalling -- the kind that would make me hate MuseScore and throw my laptop out the window. It would happen if I were to: move a note up or down, move across the score, try to play the score, do a save, or basically anything that involved editing or playing.

My conditions were similar to others: over 150 measures, roughly a dozen+ parts. It would happen even if I were to change computers, or save different versions of the files -- even, several times, starting a new file and pasting the parts in.

I've done the following. I don't know which gave me the best bang, but each seemed to help: turn off autosave, flip navigation from page view to continuous, remove all slurs (which MuseScore doesn't seem to play, anyway). Now MS responds to me.

p.s. I have never used the navigator. Didn't even know it was there until people suggested turning it off.

Do you still have an unanswered question? Please log in first to post your question.