Extremely Slow Keyboard in Scrivener

Every once in a while, Scrivener becomes extremely slow entering text into a document; about 1 character per second. It only happens in Scrivener; I have tested typing into other applications and they work just fine. In fact, I can type into other applications while Scrivener is still entering text from its keyboard buffer.

I have suspected KeyboardMaestro, but exiting out of it does not fix the problem.

At some point, the problem disappears and typing returns to a normal speed, but that is not predictable. Any ideas?

Using Scrivener 3.2.3 (14869) on a Mac Mini with macOS 12.5.1

My only experience of typing slowdown is when using Scrivenings mode on a large section of the draft with many inspector comments and/or footnotes.


1 Like

Just curious. How big is/are the document/s where you see the slowdown?

1 Like

Very few Comments (2 or 3) and no Footnotes.

DRAFT 241 files
RESEARCH 116 files

No, i was referring to not the project size but the size of the documents you are writing. Any pattern to which document shows slowdown? Same docs always go slow? Anything in the System Activity Monitor?

That’d be the first place I’d look. Keep an eye out for your anti-virus.

What’s your auto-save interval? You’ll find the setting in the Scrivener → Preferences → General → Saving tab.

Also, are you using Scrivener’s Page View?

auto-save interval is 60 seconds, just increased it from 30 secs.

This is an intermittent problem, which occurs in the same two projects I work on all the time. It appears to be independent of anything else running; and seems to be specific to Scrivener.

This time is the worst it has ever been; in the past, the problem would fix itself after a reboot and restart of the Application. Not this time, 4 reboots and many more restarts.

I have just re-installed Scrivener and the problem persists.

This problem only happens on the macMini and not on the macBookPro, for what it’s worth.

It is not auto save interval. it is the amount of idle time (no keyboard activity) to look for then do a save.

try making it 2 seconds which is default. Scrivener will then probably save less data each time and hopefully you will not notice.

At 60 seconds it may not ever save anything if you are active and when it eventually does save it will maybe save so much you will see a lag.

As noted upthread, then, it’s probably something specific to the project.

Are you using Page View?

What specifically are you loading in the Editor? I would be very surprised if a single short text file had performance issues. I would not be surprised at all if a large Scrivenings session with several hundred component files did, and even less surprised if that session also had a lot of embedded images.

Since you say the problem disappears and the program returns to normal speed, and that the problem only occurs on the Mac Mini, my hypothesis is that Scrivener is slowing down while loading a large editing session, and then recovers once it has finished doing that.

I’d recommend a happy medium somewhere in between. (My own is set to 10 seconds.) At 2 seconds, Scrivener can try to save when the user hasn’t actually paused, leading to temporary freezes.

The difference in performance on the two systems may have something to do with the kind of disks involved (HD vs. SSD) if saves are the issue.

To diagnose, you can watch that in action with the Disk panel of Activity Monitor. During a slow-down, it would show a spike in disk activity on the slow machine.

Mine has been the default 2 for many years and never ever seen any “freezes” even with big files. SSD drives.

Perhaps the default in Scrivener should be changed, then? Or have an algorithm that tests disk performance, and based on that put a recommended inactivity test time on the preferences box?

UPDATE: Inadvertently I closed the Inspector (cmd-opt I) and immediately the problem disappeared. When I reopened the Inspector (cmd-opt I) the problem DID NOT return. Nothing else has changed, same Project, same Editor setup, same Screenings view.

There appears to be some intermittent interaction with the Inspector that causes this problem.

I use Scrivenings and a split Editor on the macMini. On the macBook I mostly work on an individual file. My files contain only a dozen very small images total, 400x400px or thereabouts. I do not use Page View. FWIW.

Thank you all for your input. Cheers!!

Which pane did you have open in the Inspector?

How large a Scrivenings view?

The Synopsis / Notes pane. (Both of which are empty for most files.)

In this case, 100+ files. However, in another folder there are 140+ files in the Scrivenings and it does not present the problem. In the first case, there are three files with Tables (20 or 30 rows by 3 or 4 columns), with which I have had problems in the past. I don’t know if that might be contributing to the problem or not.

Based on your remarks, I now have a usable workaround. Thank you!!

Ah ha! Please test to see if you see the issue if you load only the files with tables into a Scrivenings session. Please also test to see if loading the 100+ files without the tables causes the problem.

Also, is the Synopsis/Notes pane empty for the table files specifically?

SUCCESS!! I can confirm that the culprit are the Tables; I relocated all the files which contain Tables and the problem was reduced to almost Zero, meaning it is imperceptible. As I relocated the files with the Tables, I noticed improvements. If I turn off Scrivenings then the problem completely disappears. The Folder contains 235 files and probably 20 or 30 small images.

Because I need to bring those relocated files back to their original position, the workaround is still the better option.

I have had many problems with Tables before; I am certain that the problems with them are well known to the Engineering Team.

Thank you much for your insights and assistance. Cheers!!

– Jorge.

1 Like

I’d put each table in a document by itself, in Research, with a section type I’d call “table”. Where they’re needed, I’d use links to them. Then they’d have no impact except at Compile time.