Score editing extremely slow

Can you spot which nightly become slower than the other? That would be very useful!

I have same issue. If you close navigation tool at bottom of the screen, it's a little better.
This occur also in previous releases, but now it's worse.
Robert

@Robert What do mean by "now"? Can you sport the nightly where it becomes slower?

My actual release is MuseScoreNightly-2013-11-14-1908-5f3b78b.7z

but the issue (not really an issue) seem to be very very old, if you don't have a good PC configuration, editing is not fluid. But my feeling is that it worsens gradually

For me the Navigator seem to slow machine. Toggle it speed up the edition, but you lose the interest of this feature.
Maybe an optimization in redraw or lesser info in the navigator will speed up significantly editing. I don't think redrawing all detail of the score in the navigator it's very usefull. Maybe view the place of the score line, frame and some text are sufficiant to have an overview in where you are in score and for me i think it's all we need to navigate in.

Robert

Marked #24111: MuseScore very slow on large score as duplicate

Agreed. Ridiculously not made for composing, but rather for documenting what you have already written. Absolutely not flexible enough to change duration, but rather deals with your score on a measure by measure basis, not as a project as a whole. Not at all what I was looking for. Not at all useful for me then...see ya.

Sounds like maybe you need help understanding how to use the application? If so, you should post to the forums, rather than to this unrelated issue report.

There has been a new report of slow scores with a reasonable size here http://musescore.org/en/node/24371#comment-93771

It seems it's mainly a Windows issue. On Linux and MacOSX, moving a note is quasi instant while it takes more than a second on Windows. The last revision d1215a32ff has two small optimizations that improve the speed slightly.

Basically it seems that layouting a large score takes more time on Windows than on Linux and Mac OSX. One reason is that obtaining the font metrics is slower on Windows. The two optimizations try to address this problem by caching the font metrics (width and tighBoundingBox) where possible.

It would be great if we could profile the executable on MuseScore like we are able to do on Mac (with Apple Instruments) or on Linux with Valgrind/Callgrind. Unfortunately, I can't find a good free profiler for Windows which support MinGW. I tried "Very Sleepy" which gives only partial information.

Salut Lasconic,

Your optimization seem to work, now it's better than previous version.
I have tested it with 53 pages score and "c'est supportable" ;-)

Merci

Robert

I'm sorry to say that while this might have helped some, it's still very slow for me. My best benchmark is a 43-page score for 5 instruments with parts generated - about 100 pages in all. Any operation that triggers a layout takes about 5 seconds. If I delete the parts, it's half that, but still, the same score in 1.3 was all but instantaneous.

I tried deleting all text to I could to see if that made a difference, and if it did, it wasn't much, either. I guess font metrics are still needed for the notes.

Hello,

Strange, my first test is without part and earing your experience I have tested the same score with all 10 parts generated and all work fine.

Maybe the reason is that In my score there aren't lyrics.

Windows 7, 64 bits

Robert

Mine has no lyrics, either. Perhaps the difference is that I am running a "debug" build under the debugger. It's somewhere around 5 seconds per layout operation - each note entered, articulation adjusted, etc.

Here, for the sake of comparison, is the score I am using. BTW, I have a PR outstanding for #23011: Change channel is broken stafftext properties. which fixes the playback so the violins & viola don't play pizzicato the whole way through.

I tested your score. My computer is not a fast computer "Intel Core Duo E6750 2.67Ghz" Nvidia 8800Gt and one operation is less than 1 second.

What is strange is that the operation on your score is slightly slower than mine. yet my score is longer. The only difference i see is that on your there are chord symbols.

Robert

PS: The fun is we are working with my wind band on "Rapsody in Blue".

On my Windows 8 system (quad core 3.4Ghz), an operation takes ~1/2 second, noticeable but tolerable.

That is very good news. I went and downloaded a nightly build (which I should have done in the first place, I acknowledge) and can report similar results - a bit under a second maybe on average per operation. Not too bad, I guess, for 100 pages of layout. So I guess now we know how much a different debug versus release build makes! And when I delete the parts (1.3 didn't have parts to deal with on every score edit), performance is worst only very slightly slower than 1.3. So as long as one waits to generate parts until one is done with most note entry - which would probably be normal - basic score editing won't seem noticeably worse than 1.3.

The one thing that will be noticeably slower is editing the parts, however. For 1.3, editing a part was usually very fast, since it didn't need to re-layout the entire score. In 2.0, editing one part also updates the score which thus forces a full layout of everything.

So I wonder if that much at least we could optimize? Don't actually layout all linked scores immediately immediately upon an edit.

As an experiment, I tried altering the loops in Score::endCmd() and Score::update() to only call doLayout() for the current score (s == this), but to still calling setUpdateAll() for all linked scores. I then added a doLayout() call to MuseScore::setCurrentScoreView(), which might be overkill (not sure all of the places this is hit) but I wanted to see what was possible.

Results are extremely encouraging. Edit times for the score are now the same speed with or without parts - still slow in my debug build, but twice as fast as before when parts are present. More importantly, edits to parts are now virtually instantaneous even in my debug build, since they aren't laying out the whole score. And yet when I switch tabs between score and part, the changes appear with layout intact (although I pay a penalty in tab-switching speed now that I am doing layout there).

I didn't bother to figure out how to handle multiple open tabs (split screen view), so if you have the score and a part displaying simultaneously, editing the part shows the score change but the layout not fixed. The layout fixes itself when you click in the other window. I assume that's easy to fix - probably my test "if (s == this)" should really be something like "if score is currently in an active viewer".

Here's a commit showing my changes, which as you can see are extremely simple:

https://github.com/MarcSabatella/MuseScore/tree/23546-slow-editing

I've been continuing to play with this (and checking in new commits on the above branch) as I'd like to get it to a place where I can issue a PR with confidence, or get someone else to take it over.

If there is an easy way to find out in from a method of class Score whether the current score is visible or not, I haven't found it. I see that I can probably check the two "tabs" (windows) of the main mscore object, but doing so directly breaks the otherwise fairly clean separation of libmscore and mscore, so I haven't bothered. Besides, it's kind of fun to make a change in one window and see the change take place in the other but without the automatic layout :-)

So far, when I defer the doLayout() call for a score, I only actually perform the operation upon switching to the tab. That's not really good; I should also perform it before saving, printing, exporting, uploading, invoking a plugin, etc. I could go and add explicit doLayout() calls at the front of each of those operations (after first checking layoutAll()). But I suspect there is a better way, one that might be more general and not come with a danger of missing some case.

Linux 64 bit, 500 measure score with 8 instruments, quite a few lines and text objects, etc. No lyrics. Each edit operation is taking about 1 second to perform. That includes changing the pitch of an existing note using the keyboard, and changing any value in the inspector.

That sounds about normal. Have you generated parts? Not having parts is better for speed. I never did follow through on my initial efforts to optimized layout by not laying out linked scores until necessary.

I've also found the recent nightlies to be extremely slow. I'm probably more affected than most with speed issues since I'm running this on a netbook with a single core 900 MHz processor.

I've noticed that the zooming and scrolling to be pretty laggy, even with small scores like Marc Sabatella's Reunion (Great piece, BTW!). In version 1.3, dragging the score around follows the mouse cursor pretty tightly. In the latest nightly (I'm testing 93e1db5 right now), the page lags a great deal behind the mouse cursor. Not extremely annoying, but a regression nonetheless. Zooming, on the other hand (with Ctrl+mouse wheel) is just plain terrible in the nightly. When zooming, it takes half a second on each "step". In version 1.3, I can barely see individual steps when zooming. In version 1.3, placing a note by clicking in the staff was instantaneous. In the nightly build, the note appears a whole second after clicking.

Perhaps the worst performance issue is probably dragging individual notes. This was pretty bad in 1.3 but still tolerable. In the nightly release, when editing a score of about 10 pages, I can drag a note and it changes about 3 seconds after releasing the mouse button.

Have you generated linked parts? If so, that explains half of what you are seeing right there. Really, aside from that, there shouldn't be any appreciable difference in speed between the two versions. Are you sure you are comparing apples to apples - the same operations on the same score on the same machine with the same other programs running in the background, etc?

BTW, why are you dragging notes? That's not a normal thing to be doing, so differences in speed of that operation shouldn't affect the majority of users at all.

Also, do you have the navigator open?

I do notice that disabling the navigator greatly improves the zooming and scrolling responsiveness, making it comparable with version 1.3. Maybe there are some extra update operations going on with the navigator? When editing, adding a new note still takes 1 second to perform (whether you're placing it with the mouse or typing with the keyboard). By dragging notes, I mean when I want to change an individual note in the piece, I drag it to the new pitch. I don't do it that often, but when I do, it's excessively slow.
I'm testing this with your Reunion score. (the one that comes as a sample in MuseScore 1.x.) There are no linked parts. I'm using this on an Asus Eee PC 1000HD (Windows XP SP3).

FYI, to change piotch of a note, the more usual way is using the cursor keys. Is that faster for you?

Yes, using the arrow keys is much faster, which is what I do most of the time. I find dragging sometimes useful when moving notes by a large interval.

The only issues that seem to degrade my experiece are the navigator drastically slowing down scrolling and zooming, and the 1 second delay when placing a note, which was instantaneous in previous versions. If those can be fixed, it would be great! :) I might start taking a look at the source code (I'm mainly a C and Java programmer, though, but C++ is similar).

Ctrl+Up/Down transposes by an octave, so arrows alone for intervals less than that, plus one or more Ctrl arrows, should pretty much always beat dragging.

As we've already observed, it is known that linked parts will slow things down by a factor of 2, and the navigator is also noticeably slower in large scores. But for scores with no linked parts, and scores of only a single page, or with navigator turned off, there should not be any slowdown at all compared to 1.3. If you are seeing something, it may be something very unique to your system. So we'd need your help identifying the problem. Best place to start would be a really complete step by step rundwon of *exactly* what you are doing from the moment you start MuseScore to the moment you see something you think is slower than it should be.

I know this issue is is kinda old, so sorry if I should not be posting here, I can create a new issue if needed. The thing is that I detected a huge slowdown that happens only when in Continuous view with the Navigator open. I made a small video to show how much the program is less responsive under these circumstances. Using Musescore 2.0.2

https://youtu.be/DzUjgLt4qFs

If the score is very large, then I'm afriad this may be unavoidable for now. Feel free to post the score itself so we can check.

I made the score available in musescore.com

https://musescore.com/user/126642/scores/1916356

The attached score has only one line of melody, mostly one line of lyrics, 780 measures, yet everything is extremely slow-- note entry by MuseScore keyboard or external keyboard, lyrics by typing or copying, correction. With notes I easily get way ahead and then there get to be duration mistakes. Windows XP. I haven't had such a problem for years. Is there a reason? It feels as if it is recalculating the lyric layout from the beginning. Mikado melody.mscz

Yes, the entire score is laid out on every edit - this has always been the case. The attachment doesn't seem to work so I can't test to see if there is anything else unusual going on. Do note 2.0.3 has a known issue where in certain cases uses of the Navigator window can cause CPU overload that would result in a slowdown. Closing or even just resizing the Navigator would fix that.

Mikado melody.mscz
Here's the file again, I hope. I think you looked at an earlier version when I had a corrupted empty measure, but maybe you didn't need to look to answer my question. Would it be possible to recalculate from the current point on, at least when there are no breaks beyond the current point? I was hardly using the navigator, and the speed decreased steadily as the length of the file increased. I have started the continuation in a separate file and the response is very fast. As an experiment, I pasted about 70 more measures onto the attachment and it seemed almost instantaneous, even faster than adding a note, but I suppose that is an illusion. But if the lyrics lay-out is as hard to calculate as I imagine, it is plausible to me that it could get slow at 750 measures.

One of the big improvements coming in 3.0 wil be incremental layout, so that indeed, only the relevant portion of the score is laid out on an edit operation, rather than the whole score. So extremely large scores like your should be much faster to work with. Meanwhile, the recommendation remains, break your score up into sections while working on it and use the Album feature to join it all up at the end.

Thanks. I have recently been entering notes and words in a separate score and then copying and pasting them into the master. I then enter the things that don't copy, which doesn't seem too slow (but apparently includes key changes and repeat signs). If I understand albums correctly, every time you add a score, you have to recompile; ditto corrections unless you make them in the master, in which case what I am doing is equivalent; and the components can't begin in the middle of a page. Am I missing something about albums?

Albums can work two different ways. You can either print them directly - which I believe does start a new page with each score but I've never tried so I can't be sure - or you can use the "Join" command, which creates a new score. If that's what you mean by "recompile", then yes, you do need do that, which is why I said to do it only at the end. But the process of "recompling" is just a few clicks, and doesn't require manuyally adjusting key signatures, repeat signs, etc, so it's going to be *MUCH* more efficient than copying and pasting. Scores can definitely begin mid-page when using the "Join" command.

I am putting together a march with only 21 instruments and the editor is acting very slow. Like most of you guys say, but when I edit any other score, it works fine (even scores with more instruments than 21). When ever I edit something, I take longer than usual (10 seconds) and always says "Musescores is Not Responding." Is it my computer? Is it Musescores? Please Help.

The number of instruments is only part of the question - also the number of pages, and how much music is on each page. Also whether you have generated the parts for all of the instruments or not. A 500-page score for 21 instruments can be veyr slow indeed. If it's only say 20 pages, it shouldn't be bad. If you attach it here we can see if there is anything going on to cause problems.

Well, I rewrote it and now it's working fine. Some parts were written and others weren't, and it would was slow. Main while adding notes. Thank you for the advice.

Alright. I have come to the miserable point where I am ready to make an account on here to rant about this same thing.

I should have finished a 10-piece arrangement (vocals (with lyrics), trumpet, alto, tenor, trombone, two stave piano part, keyboards, guitar, bass and drumset) yesterday, but the score is so slow that I can't work normally. I would like to warn anyone who is a professional using this software for work (as opposed to write one page of slashes with chord symbols for a hobby band - not that there is something wrong with it, I love when people do music on any level) and must adhere to top level standard for scoring (e.g., publisher ready, which means, you put it in front of a band and they will play and it's perfect the first time, which means, when you enter the notes, you must have all the notes in place, it must have articulation and dynamics and the score must look perfect). If you're doing this for living and using MuseScore, just log another 3 days if your score passes 20-25 pages. It is a hell past page 30. You have to click 3 times to enter a note, every other time you enter articulation the program will freeze, adjusting spacers and adjusting the position of things like lines, dynamic, chord symbols or articulation is something will take forever because the element will not follow the mouse in real time and when you release it, you will realize you have moved it too far. If you mark it and do it with arrows it will take a very long time and the program will not be responsive half of the time. And nope, my computer is not slow. When I bought it, I ordered elements like processing speed and memory so I can do other space and speed consuming such as editing videos and large photo files, as well as record music at the home studio. Those programs work just fine.
Anyway, I think most who have experienced this problem will agree that it is about the time to make this program friendly to professionals. I am sure I am not the only person who dumped Sibelius when AVID bought it, and it became shitty. Can't and won't support big business with declining quality of products and am disappointed that with bugs like this (and a few others) most professionals won't sign up so we can all collectively bring down the big corporations and monopolies. Anyway, I will probably take the last part of this medley and make a separate score.

There are things you can do to speed up the editing process in version 2.x (3.0 promises to be much better when it eventually comes out).

1. Turn off auto save. When the score is that big it can take more time to save the score than the time between auto saves. Just remember to save often.

2. Remove all sound fonts but one, this will make MuseScore require less resources.

3. Use a work file. Put the same instruments, time and key signatures in it as the main file. Use this to enter notes, articulations, dynamics and everything else that is not a system item. System items include Rehearsal marks, tempo markings, time and key signatures among a few less common items. Once the non-system items are entered, copy and paste them to the main score then delete everything from the work file so it doesn't get too big and cause the same problems. You will have to slowly add the few system items that will be necessary. You may need to move some articulations and ornaments, but most of this can be done in the work file.

There are many people who never have these issues, they have a faster computer with more memory than me, so they don't have to worry about it. I do all of the things listed above and make very good time in entering scores, in spite of my slow computer.

FWIW, 20-25 pages of 10-15 instruments is not particularly big, and you shouldn't be seeing huge slowdowns for scores like that. I regularly do 17-piece big band arrangements of at least that length, and although my computer is not particular fast at all, it's totally usable. A little sluggish, but we're talking about a fraction of second per operation, not several seconds.

Indeed, as you get larger and larger, it does get slower, and sufficiently large scores are painful to work with. But if you are experiencing noticeable slowdowns on a score of only 20-5 pages with only 10-15 instruments, there may something else is going on in your score contributing to the problem. If you attach it, we can investigate.

As mentioned, changes have been made already so that 3.0 should be much better about large scores, although that won't be ready for a while yet. Feel free to test a nightly build though if you're curious - see the Downloads menu above.

Does having a number of different scores loaded into MS contribute to the slow down?

Generally, no. If you're extremely RAM-limited it might affect things a little, but mostly, the slowdown is due to MuseScore laying out the entire score on every change. BTW, another good trick to minimizing this is to not generate parts until you are all done with major edits, since all parts need to be laid out as well on every edit.

That's a great tip!

I think that will help me a great deal.

Thanks.

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.

This happened to me and I don't know how to fix it!

This issue tracker has been discontinuer, so re-report on GitHub