My machine is a late 2014 Mac mini with a 2.6 GHz Intel Core i5 and only 16gb ram. Dorico is satisfactorily zippy; I’ve never experienced anything like what was described by the OP (whose machine should utterly trounce mine!).
One thing to check: does your project have ‘unfinished’ repeat structures, eg a start repeat barlines without a corresponding end repeat before it. If so that can cause Dorico’s repeat processing code to go into a recursive loop which will dramatically allow things down
Thanks everyone for the input.
I tried uninstalling the third-party antivirus, and there was no noticeable difference in performance between it being uninstalled and it being installed but having an exception added so that its live behavior scanning ignores Dorico2.exe, VSTAudioEngine2.exe, etc. (Note that the performance was substantially worse with the antivirus monitoring these processes.) So, I have reinstalled the antivirus (with these exceptions in place).
After working with Dorico for many hours a day for the past few days, I’ve gotten used to the normal working lag, so it’s less noticeable. I was used to [competitor] where typing a “forte” symbol and such goes in immediately, so I was used to already clicking on something else during that time. I do appreciate the underlying power of Dorico, and it’s really fantastic when it just does something right the first time which was a pain with [competitor].
I mentioned that usually the CPU usage does not spike when Dorico lags–actually, it does, and I just didn’t notice it, because one thread running at full power (out of 24 logical cores) is only 4.2% of the CPU. 
I should also emphasize again that my CPU is very powerful in highly parallel applications ONLY. It’s roughly equivalent to three i5’s next to each other. So, unless Dorico parallelizes its core operations over more than 8 threads, which I suspect it does not, it will not be any faster than your MacBook with an i5.
I’ve attached the diagnostics. This is for a score with 38 instruments and ~400 bars, which is reasonably large but should be far from the largest score Dorico can handle. Here are the relevant lines from the log:
2019-03-31 11:52:56.966 : notifyPostCommandExecute: Project.SoloPlayer.New?PlayerGroupID=-1 (3546 ms)
2019-03-31 11:53:09.896 : notifyPostCommandExecute: Project.Instrument.New?PlayerID=46&InstrumentEntityID=instrument.wind.saxophone.baritone.8vb (6106 ms)
2019-03-31 11:53:10.032 : UI Delay 2.9s
2019-03-31 11:53:10.310 : notifyPostCommandExecute: Play.SetProjectAudioEngineState?BlobID=1 (278 ms)
2019-03-31 11:53:13.636 : UI Delay 3.4s
2019-03-31 11:53:20.149 : notifyPostCommandExecute: Project.Players.Move?PlayerIDArray=46&PlayerGroupID=-1&PlayerID=6&InsertBeforePlayerGroupID=-1 (3374 ms)
2019-03-31 11:53:27.306 : notifyPostCommandExecute: Project.Players.Move?PlayerIDArray=6&PlayerGroupID=-1&PlayerID=43&InsertBeforePlayerGroupID=-1 (3310 ms)
2019-03-31 11:53:40.319 : notifyPostCommandExecute: NoteInput.Pitch?Pitch=G (2242 ms)
2019-03-31 11:55:52.821 : notifyPostCommandExecute: NoteInput.Pitch?Pitch=A (184 ms)
2019-03-31 11:53:44.090 : notifyPostCommandExecute: NoteInput.CreateDynamic?Definition=f&UseLocalOverride=0 (357 ms)
2019-03-31 11:53:45.229 : Executing command: File.Save
2019-03-31 11:53:48.419 : UI Delay 3.3s
2019-03-31 11:53:48.475 : notifyPostCommandExecute: File.Save (3247 ms)
I’m assuming the “create solo player” and “move players” commands require re-laying out the “full score” layout, so I understand why they would take 3 seconds. I don’t understand why the first time inserting a note on a new instrument takes 2 seconds–the samples were loaded earlier in the log–but subsequent notes don’t have that problem. Dynamics do cause the somewhat large 357 ms, which I was a little concerned about, and saving is very long but this project has three instances of HALion Sonic SE so I guess I understand.
Dorico Diagnostics.zip (713 KB)
There’s something weird going on. On a five year old dual-core Macbook Pro I can enter the first note on a new instrument instantaneously.
I have had a look at sauraen’s log and there’s nothing particularly unusual in there. It is expected that creating and reordering instruments will take longer than regular note input operations. The first note input command is taking a little longer than expected, but the second one is short. I think it’s quite possible that the sounds are still being loaded at that point which would explain the slight delay.
In terms of multiple cores, if you are working on large orchestral scores, then you’ll get the benefit from more cores. Parts of Dorico’s logic are able to be parallelised and other bits aren’t (after all, a large part of music layout is an inherently serial problem: you can only work out the layout for page 2 when you know where page 1 ends). You’ll see this in action if you run the Task Manager and watch the CPU graph as you load a large score. There are some phases that you see using all cores and some that are only able to use one.
I want to add that my i5 4670K with 24GB RAM takes 5-10 seconds to open the Play tab too. I’m just using the default VSTis.
Adding notes, popover elements, etc., also take about 1 second to complete where I’d expect them to be near instant.
Opening the Play tab takes a few seconds in a larger score because Dorico regenerates all of the playback information for the flow selected in Play mode in order to ensure that it’s up to date. In the fullness of time we expect to make it possible for Dorico to recalculate the changes to the playback data in the same way that it does the graphical music notation data, i.e. recalculating only part of it, and doing it after every edit; at the moment, playback data is recalculated on demand when starting playback or when switching to Play mode, and that’s why you have to wait.
Just a point on disk throughput. We’ve seen many cases where very expensive disk arrays which boast enormous throughput figures slow to a complete crawl under certain workloads. I’ve frequently had to tell customers that their $40,000 ISCSI array can only manage 1 megabit throughput when you’re writing in 16 byte chunks, due to the latency between writes. The throughput figures are all done using large write buffers. In the end we had to write our own output write caching layer into our software to make performance acceptable.
Same issue even writing to local RAID arrays if the array controller doesn’t support write caching, which many cheaper ones don’t (and to make it worse they often disable the drive’s built-in write caching to boot).
Unless Dorico is making a large number of very small synchronous (non-overlapped) writes though, this is unlikely to be in play here.