Dorico's speed still troubles me

Hi everyone!

I am working on a score with 40 parts and 500 bars. My computer has Windows 10 with an i5-6600K @ 3.50Ghz and I am using the newest version of Dorico. Working on such a score (no part-tabs open!) is quiet annoying sometimes, as actions take a lot of time, so I wanted to ask, if it’s only me, or if you have the same problems. Consider, that this is a fast machine, the results on my laptop are worse.



  • Clicking on “Add Solo Player” and waiting for the instrument-dialogue to open: 8 seconds
  • Then chosing an instrument and waiting for it, to appear in the Players-list: 9 seconds

WRITE (Galley mode, not condensed)

  • Hiding a cue: 3 seconds
  • Adding / Deleting cue: 3-6 seconds
  • Changing pitch of a note / Adding a note: 0.45-0.6 seconds
  • Changing length of rall./accel./cue by dragging: not possible, as every bit of movement requires 2-3 seconds of updating, so the mouse loses the “dragging point”


  • Works very fine for me, as nothing seems to get updatet.


  • Fine there!


  • Entering this tab the first time after many edits takes very long. Usually I print my score in the WRITE-Tab using a shortcut, as this works instantly.
    Don’t know if it is the update or because the parts are already finished, but reentering the Print Tab took only about 5 seconds.

Thanks for your replys! Dorico is such a great software and in the demo-videos everything seems to work so smoothly, but on my system, this sadly just isn’t the case. With Finale and Sibelius entering notes worked instantly, but of course they didn’t need to update everything. Maybe, if this is a problem with everyone, the Dorico team should consider to wait with certain udpates until the change is needed?

An i5 is not a slow computer, of course, but also by no means super-fast by today’s standards. Your project is also quite big, and in particular the operations you describe in Setup mode are those that are known to be the slowest in the application. Adding a player and adding an instrument to a player both cause the whole layout that you’re viewing to be recalculated (technically, adding an empty-handed player doesn’t need to do this, but for technical reasons it does). We have plans for how to speed up Setup mode operations, but in the meantime you should find that if you view just a single tab with a part layout, then save, close and reopen the project, you’ll find that doing a series of Setup mode operations is then faster, because it doesn’t need to update the full score between every update; when you switch back to the full score it will then perform all of the required updates, so you’ll only take the big speed hit once.

Print mode is slow because it also has to completely recreate the layout, and if it’s going to choose the full score layout, that is likewise the worst-case scenario, i.e. the most computationally expensive layout to create from scratch.

Thanks for your reply. That’s a good tip on how to speed up the Setup-Mode, when I have to do several things there!

I’d like to add, that I restartet my system after installing Dorico 3 because of the font-errors, which for now improved the speed by a good 100%!?
And it seems like separating a piece into several flows, helps a lot, is this a thing?

Still, if it’s a matter of CPU, I will consider upgrading my system, so at least I can work fast when I am at my office. But considering the use of Dorico on Laptops, and that those waiting times are what to expect from Dorico right now, I really hope there will be some improvements.
(As Notebooks with a decent size with i7 CPUs are still a little bit expensive. Therefor you could say, Dorico is a little ahead of its time :wink: )

I’m running a 12 core i7 and Dorico runs, frankly, like a dog, on any kind of medium-scale or larger score. It does the windows equivilant of beach balling after every keyboard input while entering music. What I think is really needed is a way to disable all of the formatting and calculation and thus be as responsive as possible for note entry.

I’ve had the occasional comment from others including Steinberg staff on this issue before as well.

Currently the philosophy is that it’s necessary to have 100% correctness (all changes propagated) prior to allowing another interaction, so priority-wise, having all parts etc correct is given priority over you entering or altering notes.

As the number of layout features grows, and more and more rules must be consulted in layout decisions on more and more objects (as you add parts and notes) and more kinds of views of objects (e.g. the new condensed views) then the amount of work that must be done to achieve 100% correctness increases. Eventually this gets to a tipping point where it’s too slow to enter notes.

Currently I see lots of advice to turn various features off (go to galley mode, turn off system track, close then re-open Dorico, have separate files for flows, turn off condensing etc etc). Clearly this is not a great solution.

Of course I’m sure the Dorico team are keeping an eye on this and optimising what they can, but I personally believe there will come a point where in order to add a new feature they want, they will need to change their philosophy. Once you’re waiting more than 1/4 second to enter or alter a note, the software becomes very difficult to use. In order to keep moving forward, I believe the Dorico team will need to start re-prioritising this change propagation work to avoid blocking note-entry on waiting for things that aren’t even visible to reflect changes. That can be done off-line (as in a background thread), or as-required (e.g. update a page of a part when you look at that page or print it or play it, otherwise you don’t need it to be correct yet).

I think that philosophy is backwards. If I haven’t entered the music yet… because Dorico is lagging like mad, there’s nothing to be correct about.

I agree. I just hope it’s not too much pain to re-factor their code once they come to the realisation. There’s a reason word processors do it this way. Imagine if you could only type 2 words a minute because of lag.

I don’t think we can count on Moore’s law to save us here.

Just a tip that might work for some, if you have Vienna Ensemble that is… In decoupled mode, for me at least, things work 10 times faster, especially on large orchestral scores.

OK, I get it that Dorico slows down a lot when working in Condensing mode. However, does it slow down THIS much, or is something wrong with my setup?

I’m working on a concert band score of about 350 bars. When I’m in Condensing mode, doing the Engrave Mode cleanup work, it takes 10-15 times as long as doing the same work in non-Condensing mode. What I mean by that is that in non-Condensing mode, if I drag a dynamic a few pixels, it only takes about a second before I can go on working. To do the same thing in Condensing mode takes 12-15 seconds, during all of which time I’m looking at a beachball.

Just to be clear, what I’m saying is that cleaning up a dense page, just dragging staves, text, the a2’s that Condensing puts in, dynamics, or anything else at all, can easily take 20 minutes or more. Doing the same thing when it isn’t Condensed takes a fraction of that, maybe 3-4 minutes max.

I really love Condensing — the choices it makes are wonderful and clear. But I won’t use it again anytime soon on a large project if I’m stuck with this lack of speed.

So what’s the verdict? Is this just something we have to live with (or not use yet — I have a deadline on this), or do I have something set up wrong?

Thanks much, as always.

[Edit] Btw, this is a project I originally did in an earlier version, possibly as far back as 2.0, if that makes any difference.

I use the condense option when everything else is done, because it slows every operation down. I am confident that the team will find a way to optimize calculations so that this won’t be such a problem to work with.

If you need to drag lots of slurs around, have you checked all the Engraving options to make sure you can’t get what you want automatically? At a quick count, there are more than 50 parameters for slurs that you can change.

Of course you have every right to want to be a perfectionist, but don’t forget that Dorico Elements doesn’t have Engrave Mode at all, and the forum isn’t overrun with people complaining that what they get by default is unacceptable. (There are a few posts from people who want to do something that Elements can’t do at all, but that’s a different issue.)

Lew, I’d find it interesting to see your project so I can see what the Engrave omde performance is like for me. Could you please send me the project? You can email me at d dot spreadbury at steinberg dot de.

Finale still has a toggle switch for “Automatic Update Layout”, as a vestige from the days when hardware was not powerful enough to cope with even its meagre helpfulness. I’d hope we’ve moved beyond that. Dorico has to do the layout work sequentially, so it can’t share it out between cores (yet): but I’d hope that it makes the most of newer hardware, which will of course be superseded year-on-year.

I certainly haven’t seen any beachballing during note entry on my 6-core i5. My scores can be quite large, but tend to be ‘notationally simple’.

I use the condense option when everything else is done, because it slows every operation down. I am confident that the team will find a way to optimize calculations so that this won’t be such a problem to work with.

Me too, Marc. This project involves taking an already-arranged score and condensing it. No writing at all. But just moving a Dorico-created a2 takes 10-12 seconds.

If you need to drag lots of slurs around, have you checked all the Engraving options to make sure you can’t get what you want automatically? At a quick count, there are more than 50 parameters for slurs that you can change.

No slurs at all, Rob, just the stuff I have to do to make a score publisher-ready. I’ve attached a screenie of the kinds of things Condensing does that have to be fixed. Stuff like dragging staves, moving molto cresc off of hairpins they’ve landed on top of, dynamics on top of slurs, and other typical collisions. And every single one of them takes 10-15 seconds. (Yes, I realize it’s a crowded page, and I may have to reduce the size — last resort.)

And Daniel, I’ve emailed the project to you — thanks for being willing to look at it. I have no idea how you do everything that you do and still have any kind of a life at all!

It’s not magic: I don’t have any kind of a life at all.


Sorry, I don’t know why my brain summarized a list of things into “slurs”.

IMO the basic problem with your screen shot is that there isn’t enough vertical space on the page for your staff size. If your publisher insists on that staff size and page size, you are in for a hard time whatever you try to do.

Thanks for contributing, Rob. You’ve provided a ton of great info over the years.

For sure, that’s the root of the problem. My publisher isn’t insisting on any particular staff size, but he does like to offer both a tabloid score for printed sales (that one was easy without condensing) and a letter sized score for download sales, hence the condensing.

But I’m painfully aware that vertical space/staff size is the issue.

(Yes, I realize it’s a crowded page, and I may have to reduce the size — last resort.)

What I’m doing is keeping the staff size at 3 spaces everywhere I can, and reducing pages where that simply won’t fit to 2.6 - 2.8 spaces. I’m applying my conductor eyes (my profession) to the project to try to keep there from being major, visible jumps in size between pages while still keeping it big enough to read on a music stand 3-4 feet away.

Which is proving to be a challenge!

Just to add my 2 cents worth:
I just completed an 8 minute full orchestra piece, with large, changing string divisions. For the most part, adding notes and content is alright (1/8-1/4 second lag) when inputting in galley view. But when editing in engrave mode with condensing on, it slows down to 1-2 seconds.

Is Dorico’s speed reliant on CPU/RAM power or both?

(Working on a i7-6700HQ, 16GB RAM).

An i7 is certainly enough. The main determiner of speed seems to be 4 cores minimum (more is probably helpful, though only to a point) and plenty of RAM.

Condensing is the culprit in your case, I think, and there’s not much to be done at the moment. Even a screaming-fast computer would still not make condensing proportionately faster.