What's on your Mac?

I wonder whether RW’s “performance issues” may be caused by using it on Macs that are full of many other applications and years-worth of accumulated “stuff”, as opposed to machines that are serving solely for web development?

I would love to hear from people who claim they don’t have problems with RapidWeaver’s performance. In my case, the worst performance killer by far is version 8’s device simulator. I simply can not use it at all.

I use the simulator all the time. If I’m making lots of changes to a page, then I’ll close the simulator first, especially if I might click to another page - since the simulator will keep forcing RW to go back to the first page until it’s been rendered. But once I have a page a about 90% complete, the simulator normally remains open on a second monitor…and I use it to bounce between iPhone/iPad/15" laptop.

As for what’s on my Mac- at 143 apps, way too much- including Adobe CC apps (of which Photoshop is often open) and Norton Antivirus, which is aways running due to corporate policy (I’m an admin on my laptop and could turn it off, but a) that would go against policy, and; b) it doesn’t bother me).
screenshot_4005

1 Like

Like @dave way, too much to list I have over 230 apps on my Mac, no Adobe CC but Affinity.

My workflow is similar, I run the simulator all the time. Most of the time it’s quite fast, sometimes (like page change) it lags behind a bit.

What’s on your Mac?
I know a number of folks that have had performance issues on stacks page. Isaiah has offered to take a look at individual projects that might be causing the issue.

Does this happen on all projects?

Interesting discussion regards simulator. I don’t use it, it’s pants IMO. Until today I just run a 2nd screen with Chrome preview. But, today I’m setting up for trying something new…

I’ve added a 2nd iMac to my desktop, on this I plan to run several Chrome pages with the website I’m working on open on each, with each being at different sizes.

“But how do you preview” you ask? By publishing the page when I want to preview! I realise on the face of it this seems insane, as publishing can take time, but I’m finding this workflow faster than waiting for a preview to refresh! (I’ve been trailing it for a while without the dedicated 2nd iMac and it’s working out fine).

It might seem overkill, but I’m confident it’ll end up a great solution. Next I need to work out how to publish to a local shared folder and have that open on the other iMac.

My Mac:
MyMac

I got around 230 applications on my Mac—some of them never used. I regularly use around 20 apps. My anti-virus is always running in the background. I need to get rid of about half of my apps.

Anyway, I’d like to know what you, guys, think of an idea of having a separate Mac just for web apps? Would that really help speeding up RW’s preview times? (Steve, I hope you’ll share your experience with second Mac).

Might have a look at MAMP Pro version. It allows to serve pages to any other device(Macs, iPhones, iPads, Windows, Androids, etc) on the same network.

1 Like

Cheers. I’ll get a look at it if this solution works out.

Yes, it happens on all projects.

I must admit that my pages (Stacks only) are rather dense with content (text and photos), but even freshly created pages with no content preview with few seconds of delay.

All my photos are warehoused and even pages with text only are previewing painfully slow. If I try to use the simulator, those times are multiplied by a factor of 2÷3.

I use custom fonts that are also warehoused on my server. I have nothing in my Resources, except site logo, favicon and pinned-tab image (combined files size: 40kB).

I have checked the integrity of my links and they are OK.

What else can affect the speed of RW’s Preview?

The slow Simulation (and preview) is nothing to do with number of Apps installed.

The issue is to do with complexity of page content, i.e. amongst other things, complexity of stacks, number of settings in stacks and number of stacks inside stacks, type of stacks framework (e.g. Foundry or Foundation) and the way that RW and Stacks works. I have noticed that there is a critical amount of page content that once a page exceeds this, that RW 7 Stacks Preview (and Export) really starts to slowdown and in my own testing of exactly the same projects files, RW8 Simulate mode with 3 viewports, takes %70 longer to Preview than RW7 Preview with the same version of Stacks and same project files. Sometimes the 3rd windows never updates but that’s another issue.

From what I have been told, RW rebuilds the entire page on every Preview and flushes all caches, so everything has to be reloaded.

On the same Mac, a similar Preview of an approximately similar single page site (content wise) using Blocs App and Solis will produce an initial Preview of a handful of seconds, and a text change will be reflected instantly across all 3 viewports that will also all sync when scrolled. From a technical point of view this is not an apples to apples comparison, but from a real life end users expectation of performance, this is exactly the same. The point here is that it is not the number of Apps on the Mac that is slowing down RW8 preview.

So the obvious thing then is just not to use RW8 Simulate and now that RM have reluctantly added back in the Preview windows width resize, to use Preview just as we did in RW7 and ignore the great new Simulate feature.

2 Likes

When you say preview, are you talking the “preview” button or the simulator?
A few seconds, is that 3 seconds 5 seconds?
What about a new project with a new page?
From your description, sounds like you have more than enough horsepower.

Here’s Isaiah post on a “step by step” guide on how to figure out what might be slowing down preview.

That’s exactly what I do (very regretfully).

Well, I simplified a bit, for an effect. When I said “fresh pages”, I meant pages with basic stacks, but no content added (as basic stacks, I consider Site Styles, Font Pro, Font Styles, Pro Styles, RWML Master, main navigation and a footer).

When I have only basic stacks on the page, without any content added, and I switch to Preview mode, it takes about 4-5 seconds to preview. When I do add my content, same procedure takes 8-12 seconds. In case of a really dense page (lots of text and few images), it takes up to 20 seconds.

Even switching within Edit mode to a dense page takes up to 18 seconds.

I have no doubt that lots of content and a multitude of stacks on a page affects Preview speed. As I suspected (and Isiah confirmed it), the quantity of stacks installed in RW also affects performance. That’s why I installed in RW8 only those stacks that I actually use. Unfortunately, in my experience, the performance of RW8 is even slower than that I have already cursed in RW7.

But not the performance of preview. Only the amount and complexity of stacks used on the page (as @Webdeersign already mentioned) is causing preview performance issues.

3 Likes

@fapkogi I was curious about this too - so when I got my new CTO Mac mini (6 core, and I upgraded it myself to 32GB ram) to replace my 2011 iMac I skipped the migration tool and started from scratch. (It seemed like time, I’ve been migrating systems since the mid-2000s).

My Mac mini is definitely quicker using the simulator, probably twice as quick, but still slow enough for the mental pause to cause irritation.

Dragging stacks around on stack dense page however is much better; a night & day type of difference.

Thank you for that, SB. That sounds encouraging for me, although I am pretty sure that having 32 GB of RAM made a positive difference in speed.

I am also planning to buy a MacMini and use it only for web development. But that will have to wait for a while, because I am about to buy a new car first and pay some taxes. I’m going to install only those add-ons I actually need and use. And I will try to make my pages less complex. A lot of plans for this new year…

The RAM may have helped a bit with dragging around stacks, but I never found RW8 on my iMac took up that much RAM. (It has 16GB.) At the end I was doing everything I could to optimize it’s performance. But I think some of it’s jus RW8. I’m able to run multi-angle editing in Final Cut Pro X on my 2011 iMac and it was only a little sluggish.

Part of my process in doing a totally clean setup of my new Mac mini was to abandon Adobe apps for good. Picked up Affinity Designer during their Xmas sale. Illustrator was the only app of theirs that I absolutely needed, (there’s so many great photoshop replacements), but Designer is fantastic. So much Adobe extension garbage all gone.

Yes, I am on a similar path. Eventually, I will get rid of all Adobe stuff. Even though I already have replacements for their apps, I find myself coming back to Photoshop (replacement: Affinity Photo) and especially Lightroom (replacement: Luminar 3) once in a while. Old habits die slowly…

1 Like

Yeah, I went full bandaid method - just tear it right off.

Another vote here for Affinity Designer / Photo. Excellent value for money and superb customer support. British designed and engineered. Both apps do everything I need.

The company I am in partnership with had a designer who worked exclusively with Adobe software for everything. When she went to greener pastures new and I stepped-in to do some of the designer work, I made the executive decision to go 100% Affinity and I have not regretted it.

3 Likes

It will interesting to see in the long term, if Affinity will create a clone of Adobe XD which appears to have come of age and now a serious player in the arena of UI development graphics which would make it a better solution for web design graphics IMHO.

As good as Affinity Designer /Photo are, they are still focused on vector illustration for print / large resolution image manipulation, and while they can also make good web design tools, there is great deal of baggage that does not get used.

I still use an old white MacBook with 4Gb ram and cheap 120Gb SSD, just for Adobe Fireworks with no internet connection, and it is a joy to use and still nothing available today is as good as Fireworks. Sure Fireworks crashes every now and then and has no SVG support, but otherwise it is lightening fast and powerful.

1 Like