Hello, I realized a local export of a very light website, to quickly have a precise idea of its weight. An action that is not extraordinary.
So I specified my ramDisk (8 GB) as a destination. I launched the export: about 780 files. Unfortunately, RW stopped at the 779th file! … The application then slowed down sharply and did not give back the use. The export was successful: I was able to exploit the files on the destination (my ramdisk).
No longer with RW, I closed the file and left RW.
Maliciously, the opening of the same file then became very slow: the edition of the texts is very very slow too. It’s now an impractical file!
The file is corrupted for me: why so much hatred! …
I could see this fact a few days apart, with versions 8.1.6 and 8.1.7 of RW! …
I went back to my website with my backup n-1 and RW is efficient again.
No return or response after 28 days of sending this post and this problem? …
I just realized again a local export of a website and it’s still the same problem, as mentioned above! …
Have you tried emailing @dan, @Aaron, etc via the supprt@realmacsoftware.com yet? If not, definitely give that a shot as that is the official support email.
Here is the current bookmark pointing to a local destination on my RAMDISK (24 GB):
SOLUTION: to regain control of the RW file, I just had to select another server in the “Publish” menu.
It is therefore the selection of a local server ON A RAMDISK which makes the file RW!
Recent versions of macOS use the new AppleFS disk format. The values listed in the Finder for “Used” and “Free” are only approximate now. Often times there is “purgeable” data that occupies more space, but that the OS knows it will be allowed to delete at some time later.
I had a similar problem when using a small SSD (which I suppose is just another sort of ramdisk – LOL). It claimed it was nearly empty, but after a reboot I the Finder seemed to synchronize up with the actual contents of the disk and it was suddenly 99% full. That was a difference of > 100GB!!! Doh!
Often time when saving files, they will be written “atomically” meaning that a copy of the file is written out, then the old copy moved to a temporary place, then the newly saved version is moved into place, then the new copy is verified, then the old copy is finally deleted. Notice that for quite a bit of that process there are two full copies of the file.
The point is that there is a lot the OS is doing behind the scenes now – and often the “free space” that we think we have can be incorrect by quite a significant amount.
I say, just make sure to have a lot of extra space available to publishing. At least hards, even super fast SSDs are super cheap now. I just bought a name brand 1TB SSD for my son for $130 on Amazon. For an old guy like me that once paid more than 10X that amount for 1MB of RAM for my original Mac, it sure seems like we’ve come a long way.
It serves me a lot of different tasks, avoiding to use my internal SSD: converting video files, unpacking, download files …
I always have an eye on him and I never felt he was full when I used RW …
But I also noted your remarks, carefully …
NB: I have just restarted my iMac for another test…
I launch RW. Create a new empty project. Add a Stacks page. Slide a Stacks module “Text”. Strike the text “Lorem …”. Set a single local server pointing to my RAMDISK. I name it and add it to the Bookmark.
I go back to the only page created: the edition of the text is desperately slow and impossible in production! …
thanks for the ram-disk details. that’s just enough info that i could try it myself.
and i can confirm that i experience the exact same results. even with no plugins or 3rd party components of any kind. everything is horrendously slow – but editing in particular is like pulling teeth.
i will get to the bottom of this – but right now have to go pick my kid up and take him to a doctor’s appointment.
but this evening i’ll dig in and see if i can identify the cause.
but for now: it’s definitely this ram disk. i don’t know why (YET!!!), but you can avoid all this pain by simply NOT doing that one thing.
I don’t have a complete answer, or a solution, but I do have a bit more info.
After each keystroke while editing text in RW, the document is marked as having changed. A number of automatic things happen after a document is marked as changed. Some views and icons are updated to reflect that there are unsaved changes. These things usually go unnoticed because they are very fast taking no perceivable amount of time at all. However since they are UI things they work on the UI thread – and can potentially block further interaction (like the next keystroke) if, for some reason they take longer than normal.
In this case something is taking an abnormally long time. Very very long. My guess is that it has to do with this process. I can’t confirm because this is outside of Stacks. @tpbradley might be able to say a bit more. With a sandboxed app in Mojavé a plugin developer can no longer even run performance profiling tools on RapidWeaver (which is a huge bummer – but this is all part of Apple’s enhanced “security” inside Mojave).
However it looks like resolving bookmarks (this is how we have to find files when using a sandboxed app) is taking much longer than normal when using this ram-disk.
There are perhaps ways to avoid doing this work between keystrokes. Perhaps @tpbradley can use this info to avoid doing it in some cases. But the fact remains that some system level tasks are taking very very long with the ram-disk – which is likely the exact opposite of what you had planned – and sometimes those tasks will have to be done, even if they are moved away from the critical timing path of the keystrokes. This means that, at least for now, the ram disk is going to be far slower, no matter what RapidWeaver does.
My recommendation would be to avoid running RapidWeaver on a ram disk. Perhaps when @tpbradley finds the root cause of this slowdown, and if there’s enough info there to file a bug report with apple, then perhaps someday Apple will correct this. However I filed a similar slowdown with HFS+ disk images (not at all dissimilar to ram disks when mounted) – that was several years ago. The radar remains open and last I checked the problem is unfixed (bug reports are filed through a system called “radar” at apple) – that was 3 years ago I think.
I’ve just had a quick play with this and can’t reproduce it. RW edits text and publishes perfectly (and super fast) to my RAM drive.
However, I did notice something odd in this hdiutil command.
The value at the end of 47075000 would equate to roughly a 23GB drive. That’s a massive amount of RAM to use up. My machine has 32GB RAM so that sized drive would only leave 9GB for the OS and apps.
For my test, I used 2097152 which gives me a 1GB RAM drive.
diskutil erasevolume HFS+ 'RAM Disk' `hdiutil attach -nomount ram://2097152`
How much RAM does your machine have? If you have 64GB RAM I’ll get jealous, open up the Apple store and start drooling over a new machine.
Maybe try the same test as before, but with a 1GB RAM drive.
Hello @tpbradley, I have 48 GB of RAM, so the system and applications still have 24 GB for a RamDisk of 24 GB.
This bug and this RamDisk story is not that big, actually … but despite the real service RapidWeaver offers us (I really like this app and it helps me a lot), I always have a corner of my head that she always seems a little … fragile! … Sorry.
…and there I go - opening up the Apple Store and drooling over new kit LOL
24GB should be fine for OS & apps but it will depend on how much you have running. I’m constantly on the edge of 32GB here and currently 4GB into my swap file.
Could you change your RAM disk to 1 or 2 GB and try publishing again? I’d just like to rule out the RAM situation before looking elsewhere.
I am under Mojave 10.14.4 (Fr) on a iMac 5K 2017 i5.
I just created a RamDisk of 1 GB.
In my RW file, I create a new destination locally:
Publishing –> Add New Destination : Local Folder –> Choose Folder… : my-ram-disk-1-go
Then, in the main interface of RW, in the icon bar, Publishing button, I chose the new destination: my-ram-disk-1-go
… and then I always have the same symptoms. All I need to do is select another destination, such as my remote FTP server for the RW file to become exploitable again (editing) …
That’s really interesting. Can I just confirm that the large 24GB ram disk wasn’t still present? Had you rebooted the machine before creating the 1GB drive?
@tpbradley
That’s really interesting. Can I just confirm that the large 24GB ram disk wasn’t still present? No
Had you rebooted the machine before creating the 1GB drive? No
@tpbradley - i can duplicate these results with a ram disk of any size. whether mounted at boot time or otherwise. i does not seem to be related to swap space. i keep a memory monitor visible – my machine isn’t thrashing – yet RW is behaving in the most bizarre slow way. doing just about anything produces beach balls.
setting the publishing destination to the ram disk is the only required change. doing that then affects everything else including editing text on all pages.
if you’d like me to run any other tests in Xcode just let me know. i’m afraid i can’t run RW in instruments any more since Mojave – but i can break during these stack long beach balls and collect stack traces.
I’ve tried reproducing this again and still not having any problems.
Oh my, I’ve reproduced it!!
I did one additional thing that prevents the problem from occurring. I created a folder in the root of the ram disk to publish to. If I choose the root of the ram disk in publishing settings everything goes slow-mo.
@studiozellige To get around this for now, just create an export folder on your ram disk.
I’ll look into the actual cause and see what I can find.
