I know. What I’m saying is that don’t actually need to delete layouts to speed Dorico up. You just need to ensure that they’re not loaded into memory.
I know every time someone says “That’s easy to code,” somewhere there’s a developer that breathes his last. But it seems this behavior could be added to Dorico, whereby an in-active layout is unloaded from the memory. If indeed that yields such an improvement in speed.
Just musing. I’m no coder.
Having things hanging around in memory isn’t a big deal in itself. The big deal is continuously updating stuff that you know you don’t want to look at, but the software doesn’t know that.
For example if you know you are going to spend the next hour messing about with the formatting of the 7th horn part, you don’t want Dorico deciding if it needs to update 300 pages of full score, every time you tweak one note. Switching to the full score layout is only one click away, which is probably why Dorico wants to avoid a long waiting time if you do that click, but you know you are not going to do it, so it helps to tell Dorico you don’t care how long it would take.
“Automatically getting rid of an inactive layout” sounds rather like a standard idea in computer science called the “least recently used” technique for moving stuff out of the way. The bad news is that in some circumstances, it’s just about the worst possible method - as the problem gets bigger, it can suddenly degrade from “It doesn’t improve things much, but at least it doesn’t make them any worse” to “it makes everything very much worse, by continually getting rid of the exact thing that you want to use next”.
The slowness is especially painful when typing lyrics, as characters get dropped unless you slow your typing speed down to where Dorico can keep up. And double-clicking on anything gets quite challenging, as you can’t double-click too fast or else Dorico won’t respond (it really should be using system event times for determining double-clicks).
And the projects don’t even have to be that big. I have a 5 flow project (Mass setting) with 4 voices and an organ part, a total of 40 pages, and even just in that context I have to really temper how quickly I interact with Dorico in order to avoid issues. I have no idea how people with many more flows or players or bigger scores can deal with it.
I’m running a top-of-the-line system (at least it was last year): Intel i7K 8700K, 6 cores, 12 threads, and 24GB of memory. There’s plenty of power available.
I recall one of the team saying this behavior is greatly improved in the forthcoming update, within the next couple weeks.
Power only helps if you can find an algorithm that uses it.
For example, formatting a multi page score is inherently sequential - you can’t do much work on page 2, until you have decided how many bars fit on page 1. You don’t know how many bars fit on page one until you know the vertical height of all the systems on page 1. You can’t calculate the height of system 2 on page 1 until you know how much music fits on system 1…
It is certainly not a universal problem. I’m not saying I’ve never seen slowdown, and I do have the lyric entry problem too, which I think is a separate issue since (as Dan says) it’s supposed to be fixed in the next update. But I’ve never encountered any other noticeable general slowdowns, even though my hardware is significantly older than yours (mid-2012 Macbook Pro, 4-core 2.7Ghz, 16MB) and my use-cases often exactly the same (5-movement choral music, 40-50 pages).
I know this might not be a particularly helpful comment, but just to point out that it’s not as simple as ‘Dorico is slow’.