No "Waiting for unoptimised etc." warning at export with UIkit?

Archetypon
1

Not sure if others have noticed, but when you export most projects, the export window sits for ages on each page saying something along the lines of “waiting for unoptimised stacks… etc.”, then after a while it starts the export.

If the site is a lot of pages this delay mounts up and can add minutes to the export time.

I’ve just noticed this doesn’t happen with UIkit3. Exports are really quick, even for pretty big sites: Presently building out a 20-page site and export takes 27secs before publishing starts. Only stacks on the page are UIkit and Scribe from BWD.

Why is export so much faster than all other frameworks? And what does that unoptimised message actually mean!

@lucas?

2

That’s more a question to @isaiah, or, well, RW… 😐

3

I remember someone used the term “blame shifting” to describe that RealMac message.

It would be interesting to know if there is something significant that makes RW so quick that the message doesn’t show.

4

That I can’t help with. Lucas would be the man to ask. All I can really comment on is that UIkit is blisteringly fast in pretty much all areas: Preview, editing (copy/pasting stacks, dragging and dropping etc.), exporting, publishing and page loads.

A site I’m working on at the mo has a small amount of content at the mo, but page structure is all there, menus, header with four 1900x600px slides, couple more images here and there etc.

Initial speed tests are nuts. Page size is almost all image.

34
341076×647 52.3 KB

6

Hey Steve impressive results.

UIkit is a framework made for speed. Take the Image component for example: In UIkit only images which are initially in the viewport are loaded, remaining images on the page are lazy loaded as they enter the viewport. I’ve also added an option so we can adjust the offset bounding (both vertically and horizontally) before the intersection is computed, default is 50vh (viewport height).

The Image component also supports the srcset attribute, which is awesome as it has to do with responsive images and screen resolutions. I’ve added an option for custom breakpoints too. We can also set a target element, so images may start loading based on the visibility of other elements (as a Slider or Slideshow for example, or any other element). In fact I’ve tried to add all options available in the framework, not only for the Image but for all other components.

Part from all these I spent a great deal of time testing different ways of loading the various resources / components and speeding the preview in RapidWeaver. I mean a lot of time testing different scenarios and techniques.

Oh and I had several months of beta testing, with the invaluable help of my dear Ricardo @Ricardo

5 Likes
7

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

6 Likes
8

BTW: If you’d like to see a very clear example of how much Stacks threads things – there’s a fun one built in to Stacks 4.

It only works if you have a lot of Stacks installed – but if you do – it makes it easy to see how much multi-threading wisely can benefit things.

Open up a Stacks page and go into the preferences and go to the last tab and check the very last checkbox: Use single thread for stack updates.

Then Quit and Relaunch RapidWeaver.

Open up the Stacks update window and click Check for updates and… wait… and wait… and wait. It’s … sooooo … slow.

Normally “check for updates” will use up to 12 processors to simultaneously perform many checks at the same time. This works well because most of the time spent checking for updates is waiting for a few slow servers to respond. So the cost of doing many at the same time is low for your machine since you can talk to many fast servers while waiting for that slow server to get back to you.

Compare that with, say, image exporting. Image exporting is slow primarily because an image has to be read from a disk (which is about 100 - 10,000 times slower than cache memory) and then process the image and write it back to the disk.

Since most disks only support one read/write channel the the slow time can’t be done multiple times. You can’t read/write multiple images at the same time from the same disk. They just have to wait their turn. So even if you export 10 of them at the same time – they all end up waiting in line for their turn on the slow disk. And just like the real world of merging in traffic – merging these threads onto one read/write channel makes all the traffic move more slowly.

3 Likes
9

@isaiah thanks for the comments and for the always speedy and friendly and kind help and support, you’re amazing.

Stacks 4 is awesome, can’t wait for the release!

2 Likes
10

I would tend to agree with @isaiah, @Lucas dedication and months of testing have something to do with it… UIkit3 is blistering fast and flexible. The best ever stacks framework for RW.

3 Likes