CPU or Graphics card? Which one has the greatest effect on previewing?

My old 2009 MacPro takes far too long to Preview some Rapidweaver pages so I was toying with the idea of upgrading either graphics card from the stock Radeon 4870 or upgrading the dual, quad core 2.26MHz Xeons to six core Xeons. Does anyone know which one will have the desired effect? And no, I cannot afford both or a new Mac!

Do you have an SSD already? That is the best single upgrade that you could do.

2 Likes

I do have a 480GB SSD mounted on a 6G PCI card so it’s pretty quick! It takes around 5-10 seconds to Preview a page which starts to add up. It’s strictly a first world problem so can live with it until my MacPro starts to ‘die’ or becomes a legacy product and unsupported (which it will be soon with Sierra).

I would imagine that the bulk of the work is put onto the CPU as it is compiling the code and exporting to preview.

A graphics card upgrade would help if you are experiencing lag as you scroll though your project file.

This is an educated guess as I have yet to do any test to confirm.

What does the cpu bench test give you?
https://www.primatelabs.com/geekbench/

My Geekbench score is 12597 (Multicore) so pretty decent. After trying lot’s of other frameworks and themes out today I think it is a combination of Total CMS pulling images into Joes Impact stack and Sections Pro. Since I’m not going to get rid of them I’ll have to live with it. I have bought a pair of used Xeon processors for $70 on eBay which should boost my CPU by around 20-30%.

You know that, when using Total CMS, the images are loaded from the server to your MacPro in preview?
Of course that takes the most time.

Sections Pro is not a heavy weight stack, code generated is kept to an absolute minimum dependent on the settings selected. Because the whole thing is modular, JS added by the child effect stacks is shared by all on the page and only gets added when you choose to do so - even so it is very small in size.

The main thing that will slow down preview is lots of images being pulled from a server (either warehouse or CMS integrated).

Yep, it’s the TCMS images being pulled into Impact that is slowing it down. Not much I can do the images are all optimised down to the bare minimum. I’ll have to live with it. At least I got a nice new processor upgrade out of my whinging ways! Sorry for casting asparagus’s on Sections Pro Andrew! It is my new best friend in the stacks world!

2 Likes

It’s a bit like someone who buys a really fast car and gets stuck in traffic jams. I don’t feel so bad about my 2007 iMac now.

I have a mid 2010 Mac Pro with 32 gigs of ram. If I try to preview a page with stacks I frequently see the same problem with spinning ball for several seconds but if I create a project without stacks and preview the page it previews instantly.

I don’t think the problem is with Rapidweaver as such or with our hardware. It really doesn’t require a Mac Pro on steroids to build a web page. Indeed I used to work quite happily with Freeway on an ancient 400Mhz G4 without ever seeing spinning ball.

My guess is that certain stacks are placing undue pressure on Stacks itself and causing a slowdown. If I use the default stacks that come with Stacks 3 there is no slowdown and the preview is instant.

It all comes down to features and compromises.

Complex stacks that users want will always take longer to parse than simple ones. Also there is a trade off between edit mode performance / preview time and the amount of code written to the published page. Lots of API calls to include or exclude certain code depending on settings will slow down edit/preview but will result in less code on the final published page. Conversely a stack can be written with very few API calls but the published page will have a large quantity of CSS that is never used but downloaded on every page view thus damaging performance.

A stack has to find a happy compromise between these two extremes for the benefit of the majority of users and situations.

3 Likes

Is there any way that Stacks itself could be beefed up to help here and reduce delays while working?

Well, I rely very heavily on stacks and, although my iMac will not run recent versions of Photoshop at all, it copes admirably with RW. I just need to replace it before it has a catastrophic failure.

1 Like

I test everything on a 7 year old macbook air and that works fine too.

1 Like

I am certainly not saying this is caused by your stacks Andrew and I have no doubt you check everything scrupulously. I have also seen these delays on projects using 3rd party themes without a single Foundation stack.

To give you an idea if I switch from one page to another in Edit mode it can take 15 seconds before the new page is available for editing. Switching to Preview takes anywhere from 5-15 seconds and generally with spinning ball. This is with RW7 that is no better than RW6.

I didn’t presume that you were saying that. The biggest single improvement on any of my machines has been seen by changing to a fast SSD.

3 Likes

I agree with Andrew, changing to a fast SSD gets you the biggest speed increase for general use. It’s pretty easy in older iMacs and have upgraded many over the years. Just make sure you get a 3.5" to 2.5" drive adaptor to mount the SSD.
I do look at my friends new Mac Pro with envy but he makes money from his Mac and I make almost nothing so cannot justify huge wads of $$$. The speed of my ‘old’ 2010 iMac was hampered by lots of external USB2 HD’s that had to spin up before some tasks, it’s probably having a similar effect on my Mac Pro as I have five internal drives and three external drives attached, it might be time to downsize the iTunes library and archive my home movies.
Finding out what is causing problems with Rapidweaver can be painful, I have only been using it for two years but have gone through v5/6/7 Stacks2/3 and hundreds of stacks/themes updates and not all updates have been smooth or made an improvement!
I am a big Rapidweaver fan but it hasn’t always been an easy relationship but for ‘plebs’ like me who have a book on CSS/HTML but use it as a door stop it is by far the best way to create websites.

1 Like

I hate to come back to this but is Rapidweaver 7 multicore aware? I still have up to a 30 second wait whilst previewing some pages! I had a look at Activity Monitor utility and never saw Rapidweaver go over 100% CPU time and before you say that’s is the most it can be I have a Mac Pro with two Xeon 2.26GHz processors with 4 cores on each with a total of 16 threads so the maximum I see is getting on for 1,600% in Handbrake whilst encoding video.
As a single core machine my ‘super’ Mac isn’t much cop really if Rapidweaver doesn’t take advantage of my processing power.

Only Realmac can probably answer this but our thoughts on this match exactly. When I use Rapidweaver it never goes above 100% in the activity monitor no matter what and I see regular spinning ball plus really slow page opening and previews.

On the other hand apps like Handbreak, Screenflow and others regularly hit 1600% on my Mac Pro and just glide along with no fuss or bother. I’ve just spent 4 days rendering a 3D animation in Maya 2016 and the Mac Pro purred away without a moment of spinning ball but the CPU was at around 1600% the whole time using 50 threads.

At one point it somehow hit 2000% and 52 threads but it’s worth pointing out that neither Maya nor any other part of the computer slowed down during this period. It appears highly likely that Rapidweaver is only making use of a single core and in 2016 that is ridiculous.

I have the slightly later 8 Core 2.4GHz mid 2010 Mac Pro with 32 gigs of ram and it’s still a great workhorse. Literally the only place I see regular slow performance and spinning ball is in Rapidweaver. Throw in a few commonly used stacks and even a 500kb web page can make this computer feel more like an ancient G3.