Could this be an option for Mac users, as well?
Hi! I opened your file and looked at flow 15 (Entr’acte). I was able to move notes about, add additional measures at the end, copy and paste music to those empty measures and transpose those pasted notes without any perceptible delay (iMac Pro, Monterey OS (12.3.1), 3.2 GHz 8-core Intel Xeon W processor with 64 GB of ram). I also changed the VSTs (you had 3 instances of HALION SE) to NotePerformer - that was fast as well. Is there any particular flow in your piece that is especially slow for you?
misnoma,
I opened your file (in Dorico 3.5) and as far as I could tell, all of your score layouts and Layouts for Parts were “on.” (Checkboxes checked in Setup Mode). You can make your file so much faster and easier to work in if you turn off (uncheck) all of the layouts (especially the scores) that you are not working on. I believe that the reason things are slow for you is because Dorico is respacing and recalculating every layout of your entire document each time you make one edit. That’s a lot of work for any computer. I hope that this helps.
algae592009—
Check in the Setup mode to see if all of your layouts (including your score) for each flow, except for the one you are working in, are “off,” that is, unchecked. If these are turned on (checked), Dorico is respacing and recalculating every layout of your entire document each time you make an edit. Let me know if this helps.
@Off_The_Fence, you’re not quite correct in what you are recommending here: you shouldn’t uncheck the checkboxes in the Layouts panel in an effort to speed up the software. What that does is remove players and/or flows from the layouts, which won’t have any effect on the performance of the software unless you’re actually editing those layouts – and of course you can only usefully edit those layouts if they have music attached to them.
The advice concerning layouts is rather that you should try to have the smallest possible number of layouts open at the same time, “open” meaning in multiple tabs in the same window, or in multiple windows.
@algae592009, there’s no direct equivalent to Safe Mode on macOS, but another approach is to create a fresh user account, reboot your Mac and log into that new account. This won’t load all of the automatically starting applications and utilities that you will typically be running in your main user account. It’s unusual for this to be a necessary step on either Windows or macOS, however. I’ve recommended it to @Snake_Cake because his system does seem slower than it should. It may well be that the slowness you are experiencing would be typical for the size of project you are working on and the power of your system. Without knowing about the variables, we can’t say.
1 Like
There is a Safe Mode (sometimes referred to as Safe Boot Mode) on MacOS. It is activated by holding down the shift key at startup. I don’t know if it is exactly equivalent to the Windows Safe Mode, but the basic concept is the same - that of preventing some processes from starting when booting.
It’s worth saying that Safe Boot mode and creating a new user account are both tests to identify the source of the problem, and not fixes in themselves.
2 Likes
Yes Daniel, and thank you for the correction.
Help me understand what I’m doing here…? What I am doing to get better performance in a very big file is working on one flow at a time, (of 20-25 flows) keeping only the score layout “on” for that flow. When I need to work in another flow, I’ll turn the score layout on for that flow, allowing me to edit speedily in that flow, in that score layout for that flow only. This seems to be working for me, albeit this is a new technique for me and I haven’t yet needed to print.
@dspreadbury @Off_The_Fence . Thanks. I have noticed that unchecking checkboxes in the Layouts panel helps a lot. But it’s a drag turning on and off , because you have to do them one at a time.
Multiple tabs or windows would be awesome. But it’s barely usable with even one.
Maybe I should make a video to demonstrate. I have same slowness on Windows 10 and Mac.
EDIT: Aha. I never opened multiple tabs or windows because changing layouts was so slow in the first one (9 seconds, hour glass cursor). But now I see that keeping multiple tabs open for different layouts is a quicker way of working.
EDIT2: Multiple Tabs is ok. But when I tried to convert one to a new window, Dorico crashed / quit unexpectedly .
This software will be so great when it’s finished!
1 Like
No softrware is ever finished! 
This may be totally left field and out of consideration, but I hit massive problems such as slow downs and eventual complete project corruption due to, believe it or not, some OpenType fonts. I was using an instance of Alegreya which blew up everything for no apparent reason - and was fixed when I recreated the project without it. Worse I bought the Encercle font to do nice circled numbers., This uses some clever OpenType features to make the number outlines, and after two weeks of going bonkers I eliminated it and all came back to life.
i an NOT saying thar slowdown problems are necessarily due to fonts, but I just mention it on the remote chance something like this may be happending to you, and it’s a corner people would not normally consider exploring.
I feel sure I have read the Dorico 4 does not support advanced OpenType features, so this may have something to with my experiences.
1 Like
Select all took a long time for me, but editing single note wasn’t too bad. I do see a fairly deep recursive call to QWidgetPrivate::paintSiblingsRecursive.
Sharing a Intel VTune profiler analysis for select all via “ctrl + a”. It looks like bulk of the time is spent on thread synchronization (semaphore, mutex). This is not really what expected as Dorico is not what I’d consider a mutli-threaded application. There doesn’t seem to be enough work when editing notes. So I wonder why we see these thread synchronization-primitives.
Maybe try to disable threading and see if Dorico actually runs faster? If Dorico decides to use threading, I’d highly recommend the TBB library rather than using Qt’s threading library. While Qt’s threading library is convenient, managing the thread pool is tricky and most application developer can benefit from a carefully implemented and tuned task scheduler such as those in TBB.
As already discussed earlier in the thread, we have already made significant improvements to the speed of Select All, which will arrive in the next update.
Dorico’s editing code is multi-threaded, but all code that involves drawing to the screen or handling user interaction is handled by the main thread. Multi-threaded editing does provide significant speed benefits, which we have tested thoroughly over the 9 years the software has been under active development. We have also spent a good deal of time investigating the use of other threading libraries, but it’s impractical to mix and match other threading models with Qt’s when Qt is managing the application event loop.
3 Likes
I bought an Macbook Pro M1Max with 32Gb RAM to run Dorico.
I still get beachballs, eg. when opening project. 
A beachball just means “the application is busy right now, and not listening out for any more input from you, kthx.”
You’re not going to do anything until the project has loaded, anyway.
1 Like
Thanks for explaining.
However, I don’t understand how what Dorico is doing taxes this 10-core CPU with ample fast RAM and SSD so much more than, say, FInal Cut Pro processing multiple 8K videos on the fly?
It’s just data.
Makes me think there are some inefficiencies in the way Dorico is approaching the work?
Video processing of course is handled by special hardware as it’s such an intensive task that it’s worth the system designers building hardware acceleration for it. Dorico can’t make use of video encoding/decoding hardware to do its work, so that kind of dedicated hardware doesn’t help Dorico run any faster – but it certainly makes working with video a lot easier.
On a system like a new M1 Pro/Ultra/Max, Dorico will almost never be disk- or RAM-bound, and it will rarely manage to completely saturate the CPU cores either. Although Dorico is multi-threaded by design, there are practical limits to how much can be parallelised in a given edit, particularly because edits tend to have multiple phases: before spacing and casting off; spacing and casting off; and then after spacing and casting off. At the very least, all threads working on pre-spacing calculations have to return before Dorico can start spacing and casting off, and likewise spacing and casting off needs to be complete before new threads can be kicked off to perform post-spacing calculations.
We are always looking for ways to improve Dorico’s performance, and we have plenty of ideas about how to achieve improvements, but this work has to be balanced against everything else we’re doing, including developing new functionality and fixing bugs.
There isn’t a computer you can buy that will never keep you waiting for big edits in Dorico. But if you have a new M1-based system, you have one of the strongest platforms available to get the fastest possible performance out of the software as it stands today.
3 Likes
So sorry to hear this because, to me at least, Dorico feels a lot slower than I would like/expect it to be… but I’m convinced that it will speed up in time! Keep up the good work. Thank you.
Thanks for explaining. The business model of Dorico doesn’t justify Yamaha allocating resources to optimising performance until users stop paying for upgrades because of it?
Must be hard to balance the need for new features vs the need, as they say, for speed.
1 Like