[BUG] Slow write speeds to disk with default coalescing
Completed
I first noticed this problem when I decided to give Marked a test, and noticed that it was refreshing constantly at a rate of around twice per second, and previewing content that was around two paragraphs behind where I was writing. In investigating the problem, it seems to be originating from nvUltra itself, and in particular, with the default “Don’t coalesce” setting for the undo engine.
- Create a test Mac account with standard permissions and log in.
For future reference—when I say I’m testing in a “clean environment”, that is what I mean. - Launch the following software:
- Marked (dismiss popups), we’ll use this as a convenient alternative to repeatedly using cat test.txt on the command-line, but feel free to double-check the results using that, as I did. It’s not a problem with Marked.
- nvUltra (dismiss slideshow and make a new Folder on the Desktop).
-
In nvUltra, type in “new” and press ↩ to create a new note. Start typing in a bit. I would say type normally here for best results, rather than using any lorem ipsum of other shortcuts. You should have a good 100 word paragraph or so before moving on to the next step.
-
Use the File ▸ Preview File(s) in Marked menu command.
Now, at this point things are already problematic, on my system. If I’ve been typing along at a pretty good clip in step 3, chances are what Marked is looking at is only a third of the content, and it will be gradually and very slowly catching up (seemingly one character at a time between refreshes).
As I mentioned, at this point (being still unsure of which was the culprit) I started using cat new.txt on the command-line to monitor the state of this file on the disk. And indeed, Marked is not at fault—it is doing exactly what it is programmed to be doing: refreshing when changes on the disk are noted. The problem is that changes are very slowly streaming on to the disk, well behind the cursor, and continuously.
In fact by the time I was done with my testing entirely and ready to log out of the test account, Marked was still registering edits being made to the disk, minutes after they have been typed in—in other words if I cared at all about the data I’d have to wait until it was done. Instead I logged out immediately ⇧⌥⌘Q, logged into my main account, and used cat to confirm the test file was truncated.
I don’t think the problem is hardware, but it is worth mentioning this is on a 2015 era MacBook 12"—not exactly the beefiest of things, and old-gen SSD if I recall correctly.
So as to the work-around, setting the coalescing grouping to anything higher than “Don’t coalesce” seems to be an effective solution. By “word”, the output stream does seem to be a little slow, but nothing that would catch most by surprise. By “sentence” looks to be quite safe, and is a good compromise between the Undo safety net and actually getting data on the disk in a timely manner.
And as an aside to the bug, that might be a better setting for defaults anyway. It seems to emulate quite closely how Undo feels in most macOS software, so it will provide a familiar result to most people. I’d admit I’ve never been a fan of character-by-character undo though.
nvUltra: Version 1.0.0 (20)
macOS: 10.14.4 / AFPS / 2015 MacBook 12"
-
Interesting. This *seems* to be an issue with using the macOS file coordinator for read/write? I apparently mistakenly assumed that it was fast, even if it prevents multiple simultaneous accesses.
From what I can tell with a brief look, it doesn't impact nvUltra performance at all, but must be queuing up file saves behind the scenes?? I'll see if I can tweak it to skip saves if a save is already in progress, and catch up at the end.
Thanks! (It did this on my 2018 MacBook Air, so newer hardware, but it is also an SSD)
0 -
Right! That's something I forgot to mention I think---CPU and energy usage was sane across the board the entire time. It would go up to around 12 or so energy "units" while typing, which is perfectly normal in 10.14, and drop shortly thereafter to 1 to 2, I wouldn't expect it any lower since it is monitoring the folder for changes. Likewise I never noticed any feedback lag while typing---it's purely what appears to be a bottlenecked I/O thread beneath it all.
Marked on the other hand suffers, but that's to be expected. With it constantly refreshing in the background, it was using 30 to 40 energy units continuously.
0 -
I tweaked the file save process to minimize queued up saves. While typing gibberish as fast as I can, macOS keeps up pretty well now. When I stop typing, there are usually around 2 saves that appear in the next second or so while watching the file.
0 -
That is looking much better, even on this older underpowered thing!
0 -
Glad to hear it!
0
Please sign in to leave a comment.
Comments
5 comments