Crappy RW performance on new iMac, old iMac, but AWESOME on 2010 MCP!

1

When I got the new iMac I moved all my apps over using Time Machine. The old iMac had a format and refresh rebuild less than a year ago, so there shouldn’t have been much in the way of “crufts” left behind.

RW gets very jumpy on the new iMac when pages get to a “reasonable” size. Dragging and dropping elements gets hit and miss. It’s just not nice to work with.

I’ve tested a project on the new iMac and the old one (2010) and the old one is a bit jumpy, but not as much. I think I just got used to it and put it down to the age of the machine.

I also have a 17in 2010 MBP. I’ve just booted it to test the same project: It’s silky smooth.

So, I’m thinking there was an issue with RW on the old iMac that has been amplified moving it to the new one. What’s my best approach for sorting? The obvious one is to delete RW and re-install, but what’s the best way to completely remove it?

The new iMac has 32gb ram and the regular Fusion.
The old iMac has 16mb ram and a SSD.
The MBP has 8mb ram and an SSD.

2

It’s that stupid Fusion drive IMHO. Knowing how out of touch that Apple are and have been for about 10 years, they probably stop the Fusion main disc spinning and you then have to wait for it to spin up to speed when you venture outside the criminally too small 32GB. If I recall correctly the original not quite so stupid Fusion discs has 128Gb, but Apple cut that down to a inexplicably small 32Gb. 32gb is the size of giveaway free Promo USB sticks these days.

3

Almost positive it’s not.

I never hear the HDD spinning up during the lags, and it’s not spinning while working on the project. Plus, the old Imac doesn’t have a fusion.

I think your hatred of the Fusion is clouding your opinions. Granted, Fusions are not exactly a good idea nowadays, but having had experience of one, they are not as bad as those with no experience think.

4

It still could be the disc going to sleep because back in 2010 we didn’t care about this too much so the disc may be spinning all the time up until a normal sleep. Just trying to discharge some Fusion drive angst and also come up with a plausible solution.

5

Move on from the Fusion drive. The problem is too consistent, it’s not Fusion drive related.

6

This is an old KB article (RW7) but might help on uninstalling RW8:

Just Curious was it “jumpy” with stacks 3?

7

Ya, it’s been like it since I got the new iMac.

8

If all other apps are behaving fine then I would proceed with a complete removal and reinstalling RapidWeaver.

I run a system pain utility called app trap that runs in the background. Anytime you delete an app from the applications folder it pops up with a window asking you if you want to remove all the supporting files and library entries. It works really well just remember if you have it running to reply no if you’re not deleting the application. It pops up for some updates to apps as well.

After you have removed RapidWeaver and all Support files and plug-ins I would empty the trash and then reinstall RapidWeaver and stacks.
Only reinstall the minimum stacks you need to see if jumping clears up.

9

App Trap sounds the job, ta. I used to use one called, I think, AppDelete, but it seems to have stopped working some time ago.

Cheers Teefers.

1 Like
10

I’d recommend taking a look at two things:

  1. Add-ons folder
    All the plugins, themes, and stacks in the adding can have an impact on performance. Yes, even the stuff that you’re not using (a smaller impact – but if you’re looking to identify a problem…)
    The point is, if you have different add-ons then you can expect performance to be different. If you want to try to eliminate all possible slowdowns, start by removing ALL addons. If that fixes things, then add the addons back a bit at a time. Use divide and conquer to identify the culprit(s).
  1. Preferences
    Small changes in the preferences can have large impacts on performance. Walk through your prefs (both for RapidWeaver and Stacks) and make sure your slow-machine prefs are set identically to the fast machine.
    Pay close attention to any prefs that change image behaviors (like auto-resizing large images). In Stacks, make sure al the dev-mode checkboxes are unchecked. Developer features are designed to make Stacks run predictably with maximum logging. That stuff slows things down a lot.
11

If none of that works, I’d say nuke the entire RW Library Container. Basically everything up and down from the addons folder.
I’m not aware of any reasons why a file in there would slow things down – but nuking that stuff is a good way of getting back to ground-zero.

12

I use an addon folder shared across all machines via DB, so I think that means rules out No.1. But… You’ve plucked a memory cell in my head with point 2. I have a funny feeling I was playing with Prefs on the new machine around the same time I started to see the lag.

Never connected the two things til now. Thanks Isaiah, I’ll start comparing them all!

13

I checked al the prefs, and the same on all three machines. :-(

Last night I did a lot of testing: New iMac, apps installed from Time Machine (from a HS machine) laggy. Old iMac (2010 HS) as laggy. I kinda thought it wasn’t but after a lot of tests, it is. 2010 MBP (HS), not at all laggy. Loaded up fresh when a new SSD was installed last year.

RW addons folder shared across them all via Dropbox.

My guess is the lag was there on the old iMac, and has ported across to the new one. I’m racking my brain for when i really started to notice, and I think it might has been around the time of the last RW update. I might be clutching a bit there though.

What do you mean by that?

Thanks.

14

I think Isaiah is referring to Library>Group Containers then look for any references to com.realmacsoftware

15

My advice (having been messing with macs for 30 years now) would be to never, ever , ever populate a new mac by ‘migrating’ from an old one, even by time machine. Just go through the process of fresh installing everything. It may take a week to get it done but your life will be sooo much better for it in the long run… :-)

1 Like
16

If you’re using Mojave then Apple has “conveniently” relocated the place where it asks sandboxed apps to store all their temp/cache/pref files. The old “Containers” folder is now called “Group Containers” and recently released apps should have their company “group ID” prefixing their already cryptic backwards company ID.

The result is that you can now find all of the RW detritus in:

~/Library/Group Containers/P97H7FTHWN.com.realmacsoftware.rapidweaver

You may also have similar containers for previous variants. My group containers folder looks like this:

~/Library/Group Containers/P97H7FTHWN.com.realmacsoftware.rapidweaver
~/Library/Group Containers/P97H7FTHWN.com.realmacsoftware.rapidweaver7
~/Library/Group Containers/P97H7FTHWN.com.realmacsoftware.rapidweaver8

RW v8.1 and later uses the first one. I still have to use RW 8.0 and RW 7.x a lot so even though I’m working on my brand spanking new hackintosh machine I have all three.

I run a very tight ship and regularly just delete these directories completely. If I can’t reproduce someone’s error, sometimes it’s little things, like the latency for creating a new unique tmp folder when there are 30,000 tmp folders in here for some unknown reason.

In most cases RW and Stacks clean up after themselves and there’s not much even worth deleting in here, but if RW does not shut down cleanly, then all of the cleanup might not happen. This is rarely an issue.

In my case automated testing may fail – producing a crash – and stranding some cache and tmp files. And on some productive days I can run automated tests all day long over and over – so thousands of these things build up all of a sudden and before you know it there’s 150GB of cache data sitting in there. 😲

Even in that really contrived situation the effects of that built up crud is difficult for me to detect, even with tools that are measuring performance. So… this is really the last resort of trying to look for odd RW behavior.

OK, what to do:

Before you begin:
Please know that this will wipe out pretty much all the RW data. This might include RW license info (RW stores its license info in different places depending on how you bought it – so your milage may vary here) – but have you license info on hand just in case.

  1. Reboot.
    Yeah, I know. Pain in the butt. But the thing is macOS keeps preferences (technically called “User Defaults”) synchronized to an in-memory database. If you yank the rug out from that database while it’s synchronizing weird shit can happen. So, really do a reboot. This time it’s not just the IT guy doing it for no reason. There’s a reason and it’s a good one.

  2. DONT launch RW.
    For the same reason. We want to delete these files before the in-memory prefs db starts to synchronize with the prefs files on-disk.

  3. Drag the folder ~/Library/Group Containers/P97H7FTHWN.com.realmacsoftware.rapidweaver to the Desktop

  4. Reboot.
    OK, I’m not sure if this reboot is 100% necessary. But I read it in someone else’s similar instructions, so I’m parroting that here. 🦜

  5. Start up RW.
    You may have to re-register RW. You will definitely have to re-register Stacks. You’ll have to tell RW where your add-ons directory lives again too.

Like I said, I would not expect this to have any measurable performance gains – but it is the one way to absolutely, positively start completely fresh. Good luck.

17

Y, I know, I know, but it was a new imac, and I wanted to play, etc. ;-)

Thanks so much Isaiah, I’ll get on to that asap.

Failing that, a clean install… grrrrr ;-)

1 Like
18

Oh, I just thought of something. And it happened maybe 4-6 weeks ago – right around the last 8.1.x update. I’m not sure exactly when, but there was a major DropBox update – and damn was that a doozy.

I’ve had to completely stop using DropBox – and I was kind of a Dropbox addict. Ha!

For reasons Dropbox support cannot identify, it gets “stuck” checking my disk for changes. It consumes 30% of CPU on 3 cores, 1GB of memory, and performs file reads ALL DAY LONG. It’s just continually chewing memory bandwidth, disk, and CPU. The “energy” tab in the Activity Monitor app show Dropbox as far outpacing every other app – and that includes Xcode and RapidWeaver – which is pretty telling. I leave my machine on 24/7 most of the time – and it never catches up even when the machine has just been rebooted and even when all apps have been idle for hours.

I’m not alone on this one. I know several people that have all left DropBox and headed for other services. I posted a thread about it on twitter recently and was surprised at the number of people that are jumping ship:

LOL, the thread starts out pretty complementary of Dropbox – like I said, I’m an addict and don’t want to give up my fix. I still have not left – I just run it selectively now. But I’ve started moving to MS OneDrive. I’m not sure if it’s any better to be honest, but ¯\_(ツ)_/¯ i needed to try something.

Also: you have to reboot to get it to go away completely. And make sure it’s not in your Startup Items. Once Dropbox launches it will create several background deamon processes like Dropbox Finder Integration – these are the processes hat consume the CPU. And simply quitting Dropbox doesn’t kill off these processes. In my case these 3 processes just remain as revenant zombies still chewing 30% of the brainzzzzz of my machine. 🧟‍♀️🧟‍♂️🧟‍♀️

In my case, doing this one simple trick of not ever starting up Dropbox immediately results in faster disk access, more CPU bandwidth, and my system starts running cooler.

Anyway – one more thing in your list of stuff to look for. :-)

1 Like
19

+1 for shifting from Dropbox. Completely unusable now.

2 Likes
20

Yes, interesting, i did think it was connected to that, as it appeared to happen around the same time, but… All my work machines use the same shared RW addons folder on Dropbox, so I kina assumed that if that were the issue, the 2010 MBP would suffer the same lag, but it don’t.

I have activity monitor open all the time on all machines, as i like to see what is happening, I didn’t notice any increase from DB, but defo worth turning it off entirely and checking things out.

Again, thanks.

Oh and yes, I’m looking to move from DB now. Not for performance issues (at least, not yet!), but simply because of the underhand way they just increased the price on me: Trying to “sell me” a price hike dressed up as loads of services I don’t want is piss poor. If you need to put up prices, just be honest. Increasing your price is nothing to be ashamed of, it shows good business planning. Bullshitting about why you’re doing it just leaves a bad taste in the mouth.

I’m considering moving to Google Drive, but as yet can’t find anyone who has shared their Addons folder via it, so I’m nervous!