The 2.1 plunge
I decided to try out 2.1 to see if it would make my big score go faster. The answer is absolutely not. If anything it was slower. There were no errors in loading it, it just seemed to go slower. I'll keep trying it out over the next few days to see how it works. It will get a little getting used to as I redo the shortcuts I'm using in 2.0.3
Comments
Thanks for testing! We do know that the changes to the layout algorithms that will speed up large scores in 3.0 do not apply to 2.1, but it shouldn't be slower, either. Are you sure there's a real difference?
In reply to Thanks for testing! We do by Isaac Weiss
I'll put a clock on it and let you know if it's slower.
People are often suggested to try slow scores in 2.1, but those are probably because of the navigator which I don't use.
In reply to I'll put a clock on it and by mike320
The suggestion to use 2.1 for performance reasons is only because of that navigator bug, which at certain size settings sometimes hogs a core in 2.0.3
In reply to Thanks for testing! We do by Isaac Weiss
The results are in...
I did the following in the exact same order in both 2.1 then 2.0.3 using the stop watch on my phone. The results are interesting. The score is 822 measures long with 61 staffs. The file size is 778 KB.
2.1
load 48 sec
use arrow to change a note in the first measure 6 sec
undo that change 5.5 sec
switch from page to continuous view 4.3 sec
switch back to page view 6 sec
save score 11 min 45 sec
2.0.3
load 41 sec
change note 6 sec
undo note 4.5 sec
page to continuous 4.25 sec
back to page view 4.5 sec
save 10 min 30sec.
Needless to say, auto save it turned OFF while editing this score. All measure edits I now do in another score and paste them over the existing score. This such as system text I don't do too much of, so the wait is bearable. There is a 10-20 sec delay whenever I press the spacebar to start playback, so I try to make sure as many corrections as possible are made before restarting it.
The answer is 2.1 is a little slower than 2.0.3. I can live with it, but I really can't wait for 3.0 to be released.
In reply to The results are in... I did by mike320
I wonder if this is a fucntion of how it is built and installed, not inherent to the code? Really shouldn't be any significant differences in performance at all from what I know of the changes. So, maybe the nightly builds are compiled with debugging turned on and optimization off? Or the drive you are running the nightly build from is slower than the drive you installed 2.0.3 onto? Or something like that?
In reply to I wonder if this is a by Marc Sabatella
I only have one drive and did nothing to change what was running with the the 2 instances. Both were open at the same time and the one not being tested had no score open. This is a small difference that I noticed. I realize that some of the differences were near 20% in time, but that time is (mostly) short. Perhaps it is because of debugging data and lack of optimization as you suggested.
In reply to I wonder if this is a by Marc Sabatella
I was going to say the same thing Marc is saying:
In reply to I was going to say the same by ericfontainejazz
As far as I know, nightly builds on mac and windows are built in release mode. The time changes are in the error margins according to me. An obviously killer is "save 10 min 30sec.". 10 minutes to save a file? I never saw that.
I tried https://musescore.com/user/6105546/scores/2843936 for example and saving it takes less than 30s. And part are extracted so MuseScore needs to save them too.
In reply to As far as I know, nightly by [DELETED] 5
That file took slightly less than 5 minutes to save in 2.0.3. I didn't bother doing 2.1 since I know it will be a little longer.
I have a 2.1 Ghz 4 core AMD A6-3600 processor with 1.2 GB of memory running windows 10. I haven't defragged my hard drive for a very long time, but can it make that much of a difference? I guess I'll have to find out.
In reply to That file took slightly less by mike320
1.2GB is pretty little memory, Microsoft claims you need at least 2GB (for the 64bit version, for the 32bit version it is 1GB)
In reply to That file took slightly less by mike320
I'm on MacOSX with a SSD and 16Gb of ram. Disk access time might be the problem here but we are talking about less than 1MB of data...
In reply to That file took slightly less by mike320
Windows has tools to inspect memory use, disk i/o performance, and so on. It might be that your system is throttled because it is out of RAM and is using the disk as a RAM extension. If that is happening your system will slow to a crawl. You can use the tools in Windows to look into that. Too bad that I left Windows behind years ago so I can't provide specific steps. But Google will find some guides on the Interweb, no doubt.
On the other hand perhaps there is something wrong with your file that is causing the slowdown problems. What i would try is variety of tricks such as export to MusicXML, import to a new file. See if that performs better. Also build a new file and copy/paste in sections of your score progressively, and see if performance changes dramatically after each step. And so on.
You could also attach your score here and see if someone will take a look at and see what is going on using their machine.