I was a little dismayed (a lot to be honest) when I realised that Rapidweaver 7 only uses one of my 8 available processor cores! I have been wondering why previewing pages can take up to 30 seconds or longer! Macs have been using Intel multicore processors since 2006 and Rapidweaver doesn’t take advantage of them! Why not?
We’ve been having this discussion on another thread but I’ll just weigh in and add my support on this point because taking anything up to 30 seconds to preview a web page with a few stacks on a Mac Pro is ridiculous and it’s the only app where I feel like I am working on a ZX81.
It would be good to have some explanation on why Rapidweaver is maxing out at 100% CPU on a Mac Pro when other apps commonly allow 1600% CPU without problems or spinning ball.
There was talk during the beta testing stages for RW7 of vastly improved page preview speed but I never experienced this and then we were told this was being dropped until later. Was this a plan for multi-core processing to be enabled? At present RW7 may actually be slower than RW6.
Can we have some information? @dan
Indeed, project opening, page previews take forever and I was wondering why. I did not realize that RW only utilizes one core. This must be the last application on a Mac in existence that does that…
I’m using a basic screen grab application here that appears to be using 8 cores. Rapidweaver is essentially an application that should help with design productivity but keeping us waiting with spinning ball and delays on virtually every operation is anything but productive.
On the Mac Pro RW7 reaches 100% CPU whilst on my 2.3GHz i7 MacBook Pro it gets to over 150% CPU. RW6 also gets well over 150% CPU on my Mac Pro and I have timed previewing a demo project with RW6 which beat RW7 by 5 seconds! I love the new features of RW7 but am definitely not feeling the promised speed increase!
Rapidweaver does seem to have multicore support as I have seen it on an i7 MacBook Pro get a CPU usage of over 150% but on at least two Mac Pro systems it peaks at 100% even when taking 30s to preview a page. Whether this is RW7 or a Stacks 3 problem I don’t know but my ‘super’ Mac is feeling sluggish or say the least!
I think it’s generous calling 150% multicore. It’s not even two whole cores!
This may even be an anomaly in the activity monitor that is over reporting the true CPU usage. I saw this earlier in the week when the activity monitor reported 2000% usage for Maya, when the theoretical limit for my computer is 1600%, which is regularly hit.
The more crucial point here is that working with Rapidweaver sees unacceptably slow delays and spinning ball that should not occur in 2016 with the 7th generation of a design application.
I am not expecting Rapidweaver to ever need anything like the full power of this computer because we are only talking about a few Jpegs and some html but it should run like lightening. Switching and previewing pages should practically happen instantly.
Multicore support is something we’re actively working on. RapidWeaver 7 allowed us to put a bunch of things in place for this, and we’re constantly improving it in each release.
The size of RapidWeaver’s codebase means this isn’t a small task, and we’ve got to make sure we keep compatibility with your favourite plugins too.
It’s coming a little bit at a time - but it is coming. We’ll get there, and it’ll be amazing
It has been many, many years (perhaps 30??) since that first “IBM Turbo clone” with the 20mg HD) and watching that speed burner compile a program change, line by line …
Every year since then, Microsoft always has said that the next version of Windoze would immediately solve all the problems of the last version. Of course . . . that never happened because any major update introduced new “issues”. Changing to the Apple world immediately changed that but in a new way: Apple would simply abandon software completely instead of fixing it. IWeb and Bento immediately come to mind; there are others.
I sincerely hope Rapidweaver is a strong exception to this law. However, with history as a guide, this is implausably likely.
It’s good to know this is coming, but with reference to the first post, Intel multicore processing has existed on Macs since 2006. Do we have a timescale for this? It really is bad just how slow Rapidweaver is simply selecting and previewing pages and all the other apps I use switched many years ago.
I think RealMac should take a good look back at its own history and recognize that some parts of RW are in dire need of fixing before any new features are added. The most important functionality and the interface should be fixed first.
Remember the launch of OSX Leopard and then Snow Leopard? This is what I’m talking about. While Leopard was flaky and buggy, Snow Leopard tightened up the system, squashed bugs and speeded things up, while introducing very few new features. It turned out to be one of the best OS versions ever.
I understand your concern. I’d be sceptical too! However, take a look at what we’ve improved between RapidWeaver 6 and 7. There are so many improvements throughout the application - the release notes don’t even start to cover all of them. RW7 was a huge release.
What I’m trying to say is the RapidWeaver team have done some really great things already, and we’re constantly working on improving it. I can’t give a timescale for this specific improvement since we don’t have one yet, but you will see some great performance improvements in other areas very soon (some of them are already being tested by beta testers - email @dan if you’d like to get in on that).
For me this lack of speed is the single biggest headache in Rapidweaver and RW7 appears to be slower than RW6. FTP is still unreliable but I can sidestep that and use Yummy FTP instead. Slow performance, spinning ball and delays previewing pages is a huge brake on working productively.
@ashleykaryl if FTP is still unreliable for you, it’d be great if you could send some details to firstname.lastname@example.org so we can fix it. Specifically, what happens when you try and publish? What makes it unreliable?
The FTP error messages and strange behaviour change constantly, but it’s been like this since I first installed RW6, so I have stopped troubleshooting and switched permanently to Yummy. It’s not ideal but it’s a practical alternative. The serious lack of speed while editing is a far bigger problem.
You should give the FTP engine in RW7 a try. It’s a significant improvement over what we had in RW6. If you hit any issues with it, please do report them.
I have done and it’s actually become worse since leaving beta. I also tried reporting some of the problems but the log file for the email was over 150mb if I recall correctly.
In the past I used Dreamweaver and Freeway for FTP without issues and I think there is a limit on the amount of time developers can reasonably expect people to spend troubleshooting paid software.
Funny. I have never had FTP problems, neither with RW6, nor RW7.
Actually in RW7, the upload is even much faster than in RW7.
As I say - we’re working on it /cc @dan (who hasn’t seen this yet)