I suspect @Lucas’s dedication to making it fast is what makes it fast. It’s not one particular thing, but a wholistic focus on achieving that end.
It’s a rare thing, to be dedicated to speed. And I would encourage you to support @Lucas and vote with our $$$ – I can scream and dance and shout about speed all day – but $$$ talks.
But, if I was forced to choose, I’d say his image stacks and perhaps the size of templates are the two biggest contributors to speedy export time.
As for the “unoptimized” message…
It’s a long story, strap in. 😋
Way back in RW 7.5 the app decided to use multi-threaded export and export many pages simultaneously.
Because this initially required me to do months of work in weeks time Stacks pages could not be ready for this change. RapidWeaver installed this message as a way to suggest that Stacks pages were not participating in multi-threaded export.
That said, Stacks has (from v1.0) tried to make use of multiple threads to do large computing faster – but not in the simplistic way of just throwing everything on a background thread and hoping it works.
Since RW 7.5 I’ve done a lot of research into threading and ways to speed up stacks – but I still don’t participate in the RW mechanism. Why? Because it’s slower. And not just a little bit. I wrote a blog post on some of the investigations last year: https://isaiah.micro.blog/stacks-dev-journal/
So, Stacks will get faster and more multithreaded each year – which is great since the user base has, on average, a lot more processors – but I’m unlikely to ever allow multiple pages to export simultaneously. This is unlikely to be a speed advantage unless your Stacks pages are very very trivial – in which case you probably don’t much care about speed. 😝
Isaiah