As a very vocal detractor of RM & RW of late I feel it’s only right that I also give credit where it’s due.
I made the switch to RW 8.1.6 today for a project that is 90% ready to go live. Previously I’ve not used Simulator as it was a bit pants, so I stuck to my usual method of having Chrome open on an external screen and I just refresh when needed.
To try out 8.1.6 I swapped out Chrome for Simulator… WOW!
Previews of changes are almost instant. I add an element to the page, or change something existing on the page, glance at the Simulator window and it’s pretty much reloaded the preview as soon as I’ve finished editing the page. it’s really really fast. Perhaps not Blocs fast, but considering it wasn’t unusual to wait 30 secs for a preview in Chrome, it’s way wat faster than anything else I’ve ever seen in RW.
And this site is not a simple affair. It’s loaded with my usual BWD stacks that typically put RW preview under a lot of pressure.
Machine is not new, or even modern, it’s a 2010 27in iMac with upgraded ssd and ram maxed at 16gb.
10 Likes
I’ve also not used Simulator—my reasons were same as yours. But thanks for heads-up. Time to try it again.
BTW, as I mentioned somewhere before, I noticed also that switching language versions in RWML stacks in Preview mode are instantaneous in 8.1.6, unlike in previous versions of RW.
i’d be curious if you’ve measured any apples to apples comparisons between versions on the same project file.
i have. a lot. it’s kind of all i do recently. LOL ;-)
i don’t know of a single difference in performance in any recent version between 8.1.0 and 8.1.6 – that’s several months and many updates.
and there has been only one change in stacks since early November. it was cosmetic, nothing to do with performance.
i did add a small performance update between v.3.6.0 and previous versions – but that was last summer i think. not exactly recent.
that’s not to say what you’re seeing isn’t real. it may be – but if so it’s likely very project related. and in that case i’m super interested. i would love to see a project that displays a marked change in recent performance.
if i can get a copy of that project file then i can run in through the debugger to understand what changed and what caused the big change – and perhaps use that info to benefit a wider group of projects.
if you have details, can you send them in a DM?
thanks
isaiah
@isaiah,
I think a lot of folks stopped at 8.0x because of issue with sandboxing. If I remember there was pretty substantial changes in performance from 8.0x to 8.1 in preview.
there were definitely some bugs fixed. that’s for sure. and maybe that’s what you mean.
the large slow part of the export necessary to display Preview or Simulation view is Stacks. And obviously RW 8.0 --> RW 8.1 didn’t change stacks.
but that’s kind of why I’m curious exactly what the details are here. maybe there was some change in one of those versions that had some sort of affect on stacks. if that’s the case, i’d like to understand it a bit more.
I am always super curious when I read about performance improvements in RW.
However, I just did an Apples to Apples comparison, using a large project file with RW7 and RW8.16 for both simulator and preview and found them all to be exactly the same time to preview, make a 1 character txt change and then simulate or preview again. I could not see any difference. between them and certainly no speed up.
I’ll believe when I see it. Preview and simulator in RW is one of their biggest letdowns.
This would be my expectation.
RW8 does a lot more multi-threaded work over RW7. But the two slowest parts are:
- template processing – a single threaded operation
- writing exported image to disk – you only have one disk I/O channel
I wrote a long blog post about this particular point a few months ago: isaiah - Stacks Dev Journal - THREAD ALL OF THE THINGS
In upcoming releases (not v4.0 sorry) I’ll be introducing some changes to the Stacks API that I hope will produce real, measurable, and hopefully substantial speed improvements for the slowest bits of RW: export preview and publish.
These API changes actually started in Stacks v3.5 with a new preprocessor. And a lot more developers are using that now. It’s a small win – about 20% improvement on most stacks. But you probably don’t notice it. Each developer opts in to utilizing it one stack at a time, so the changes trickle into your projects gradually.
Oh, don’t get me wrong, there will be some speed improvements in Stacks 4 too. On some projects it might be pretty noticeable. But to really affect some big change, I’ve got to break a few things in order to fix the big things. And introducing breaking-api changes on a paid upgrade – woah – super bad idea. So Stacks v4.0 is all about making Stacks easier to use.
There are some things that RW can do to help out too to help with performance. I’ve requested they make some API changes that will help plugins cache some of our exported data between previews – right now not much can be cached, which is a big limitation.
@isaiah Thanks for your thorough explanation. As always you show us a deep insight into your world.
I have to say that I have not noticed any performance increases with the use of many stacks that had updates to take advantage of Stacks 3.5. Where I have seen performance increases or rather reducing the slow performance using stacks is in 2 areas:
The first is using one Framework over the other Framework and as I build my projects using both Frameworks, I see this every time I build 2 versions. Is this due to SiteStyles vs Foundry Control or because 1 has tool tips and the other doesn’t or something else?
Secondly, I find that creative use of the best stack for the application is also really important to reduce delays. The decisions on what stacks combinations to use, are the tricky decisions. E.g should you use 3 stacks inside each other to replace 1 stack that provides all 3 functions? Tav has done a lot of work removing functionality into Child stacks and that certainly helps performance and also simplify the Edit view.
In the past, I have certainly been guilty of throwing the most powerful stacks into projects when I could have used the simplest stacks for my main freelance work. My original thinking was that using the most powerful stacks would make it easier to add more functions in the future should I need to do so.
It would be interesting to hear other’s experiences of wringing the most performance out of RW +Stacks.
First off, I can’t ever answer questions comparing stacks. It’s important that I’m not only impartial, but also make sure everyone knows that I’m impartial.
Foundation and Foundry have fundamentally different implementations. This likely comes from different priorities more than anything. Where one might favor edit mode performance the other might prefer more accurate edit mode rendering.
I would encourage you to give feedback directly to the developer of the stacks you find affect performance. The one thing that consistently surprises me is how oblivious most developers are to this issue. I think if they realized how much it affects their users, they would work harder to find ways to speed things up.
Simple things are always faster. Complex things are more flexible. It’s a tradeoff.
But it’s more than that too. Breaking things down into multiple small stacks lets each of those things be rendered and cached independently when it’s properties change.
Recently I was sent a one-page project that took 15 seconds to open and 5 seconds to preview. I was able to speed it up substantially just by replacing one very complex stack for a Text stack. The designer wasn’t using the complex stack at all. It had just become their de-facto replacement for Text stack. But each use of that stack takes 450ms to render (about ½ a second). So use that stack a dozen times and boom – 6 seconds.
That experience has lead me to the conclusion is that part of the performance problem is objective measurement. Without a way to collect real performance information it’s difficult to understand what is causing the largest slowdowns.
Some measurement data will start to appear in the developer console in Stacks v4.0 – and more will appear for regular users a bit later – maybe v4.5.
I’m not certain that will immediately help much – but shining a bit more light on the slowest stacks probably can’t hurt.
Isaiah
3 Likes
Agreed. Wouldn’t that be a good thing.
1 Like
@Jannis take a peek in the dev console. the css template processing time should already be displayed. more soon.
1 Like
Sorry, not read the above as flat out at the moment, but… It appears I shot my load a bit too soon.
I first tried Simulator back when it came out, which I think was RW8? It seems it’s not changed much since I first tried it, but what has changed is how I build my sites. I’ve changed out a lot of the regular stacks I use lately and this seems to be what has caused the increase in speed.
When I posted that above it was on a new site I’ve built recently, and it does indeed fly along in Simulator, as so some of the other new sites, but as I’ve been updating some older sites the last few days Simulator is like treacle again.
Sorry for the mis-info above, note to self: Test stuff a bit better on old AND new projects before getting shouting my mouth off.
I will get back and read the above when I have a spare few days ;-)