Poor Scrivener performance [with comments and footnotes inspector tab open]

I’ve actually given up using Scrivener 3 on Windows, exactly because of the sluggish performance.

The problem is most obvious when right-clicking on entries in the Binder - it takes several excruciating seconds for the pop-up menu to appear. Other basic UI functionality is similarly lethargic - to the point that using the software is impossibly irritating.

The problem is all the more obvious given that Scrivener 1 works perfectly on the same PC - the software loads and runs like greased lightning, all basic functions truly instantaneous. (I also use the Linux version 1 on an ancient Pentium PC, and that too works splendidly.)

I am led to suspect that the new Windows version 3 was totally rebuilt using none of the version 1 code, but instead ported from the Mac using some sort of intermediate toolkit. I can’t imagine any other way of introducing such an huge delay in basic UI functions. (The fact that fonts are obviously rendered very differently in version 3 tends to confirm this conclusion.)

I’ll grant that this problem might not be apparent on the newest PCs. (With current prices sky-high, it may be a long time before I can find out.) Nonetheless, this issue really does seem indicative of lackadaisical coding. One should not need a ‘monster’ PC to run something as basic as a word processor. What’s more, my current PC is no slouch - it runs things like Adobe Creative Suite, Microsoft Office and a lot of recent game software extremely well. So why should Scrivener alone be dragging its digital feet??

I do like a lot of the new features in version 3, so if there’s any fix for this performance problem, I’d be extremely glad to hear about it. If not, I guess I’ll just have to stick with the excellent version 1 forever. (As a bonus, version 1 lets me maintain the link with Linux, a big plus - I expect to transition all my work to that superior, forward-looking platform over the next couple of years.)

I use Scriv3 under Windows 10x64 on a 12-year-old Dell laptop. I’ve run a 110,000 word novel through it for several months or so with no lag whatsoever. Just sayin’. Of course, your mileage is obviously varying.

1 Like

Thanks for the input, Twolane. Unfortunately, my mileage not only varies considerably, it basically sucks.

I just fired up Scriv3 again, and did a bit of rough timing. From when I right-click on a Binder entry, it’s a full three seconds before I see the pop-up menu. That’s simply not usable. In Scriv1 the pop-up is essentially instantaneous.

Somewhere in their reams of Scriv3 code, L&L has opted to leave me behind. The fact that few other purchasers share my fate is no consolation whatsoever.

Just wondering, @flange, have you given Scrivener support an email with an example project, so they can see what’s up with it?

I think we’ve gotten to a root with others experiencing opening delays by discovering they were using very large single text documents.

This has always slowed down any text editing internal component for an app, past a point and for sound basic software reasons: formatting is costly and gets more so if you do lots at once. Visibly long stream—apparent editors like Word get around it, as far as I know, by magically behind the scenes breaking texts up into manageable blocks; it’s just that you never see so on the user screen, which is always comparatively small.

To do that breakup and manage it is a big problem itself, and Scrivener doesn’t need to solve it because you are encouraged to write your text in short (document) blocks, the better to be able to move and reorganize them, one of its strongest features.

So if you work as intended, as far as I know, that’s where others have no problem with slowdowns. Persons who did lose the problem by breaking up their project this way, as they have reported success.

It could always be another; even something gone south on your PC, as too easily can happen with Windows, or the consistent bogey of inept, often free and getting what you pay for virus checkers which don’t get along with Scrivener, particularly at installations. It seldom pays to feel clever this way.

Thus again, if you try at least a test of making your document chunks smaller, and still have the problem, that’s when it would be a good idea to give actual Scrivener support a chance, which they handle by email.

Best fortune, of course

1 Like

I may try Scrivener support at some point, but without any other reports of similar problems I’m not optimistic they’re going to spend a lot of time on my case.

To be clear: the issue has absolutely nothing to do with loading or with the size or complexity of the project. The UI is simply too slow to use, from the get-go. The projects I’ve used for testing have included ones that load and run beautifully in Scrivener 1, as well as new ones I started from a blank slate in Scriv3.

Organizing text in blocks is something I’ve been doing since the 1990s, using products like GrandView, Manuscript, Agenda, PC Outline and Ecco Pro. (I continue to use the latter on both Windows and under WINE on Linux.) Scrivener borrows a lot from these earlier products, and hence poses no mystery to me.

Regarding my PC, I can only reiterate what I said in my previous posts: it’s a dead-stable machine, doesn’t misbehave at all with any other application. As someone whose career has included a lot of software testing, I am a fair expert at troubleshooting Windows. I also tend to have a LOT of apps on my system - big ones like Adobe Creative Suite and Office, open-source apps, games (many hundreds in my Steam library)… you name it. I routinely use three web browsers, two email clients, two word processors, two ‘office’ suites, two video-chat apps, a considerable number of graphics and desktop publishing tools, video editors, music editors, e-book editors, PDF tools, and much more.

Clearly, my PC is somewhat unique. But when ALL of my other software runs perfectly and only Scrivener 3 misbehaves - in a rather peculiar way that I’ve never seen before - where should I guess the problem lies?

As I’ve said, given the lack of other complaints, I have to assume there is indeed a factor that sets my PC apart. Clearly, however, there is ALSO something different about Scriv3 that is not present in any of the other software I use. (Including, most conspicuously, Scriv1.) My main hope is that someone else may be seeing the same issue from a different angle.

Please do get in touch (or make a proper thread for it here). What you describe is certainly not normal behaviour, and given that, there is probably some explanation for it somewhere. Just because a problem is unusual doesn’t mean we don’t care!

2 Likes

Thanks for the concern, AmberV. I’m not worried that L&L doesn’t care! Simply going by my experience - outlier problems like mine don’t tend to get solved except by happy accident, or an accumulation of user input. Smaller companies like L&L obviously don’t have the resources to troubleshoot them all in depth (and larger companies with huge market share can’t be bothered).

But I will take your suggestion and file a proper support request in the next few days. The solution may be quite simple - the trick is finding it among a vast range of possibilities.

1 Like

There are, broadly speaking, two possible causes for your problem:

  1. A bug in Scrivener. This is possible, but unlikely because if it were a general issue we’d have more reports.

  2. Something specific to either your project or your configuration. These can indeed be time-consuming to troubleshoot, but I would say that the majority of our support time is spent on user-specific problems. Not because user-specific problems are common, necessarily, but because the common problems are documented in the manual and therefore easily solved.

So please don’t decide your problem is unsolvable without at least asking the support team for help. You might be surprised by the amount of effort we’re willing to put into resolving this kind of thing.

2 Likes

it would be great if when you solve this (and i am sure you will) that you post here the problem and solution.

1 Like

FYI, I’ve split this off into a separate discussion. The original thread was restricted due to some overly enthusiastic participants.

2 Likes

On my computer, it goes so fast that I can’t really tell, but, if I am not mistaken, Scrivener only loads a file when it needs to display it for the first time since you opened/loaded the project. What I mean is that I don’t think it is loading everything up right from “project open”.
Right-clicking a file in the binder would also load the said file in the editor.

My point being : perhaps, as it seems to be responsible for so many other (but potentially related) issues, CHECK YOUR ANTI-VIRUS.

White-list Scrivener and see.

2 Likes

I realize that suggestions are well-intentioned. But please do assume that I’ve tried the most obvious fixes.

For example: antivirus software. I never use it. In my (long) experience, it creates far more trouble than it prevents. (Your suggestion, Vincent, only tends to confirm this.) I do use a very good software firewall, but I whitelisted Scriv3 upon installation, and have since tried disabling the firewall entirely - no effect.

The problem does not relate to what file is open, or how big and complex the file is. Even with a brand-new, completely blank project, right-clicking on Binder entries results in s a three-second delay before the pop-up menu appears. When right-clicking on text in the editor, the delay is shorter, probably less than one second - but still annoying.

As I recall, there are other slowdowns as well. Everything generally feels sluggish - in marked contrast to Scriv1, which feels light and nimble at all times. (It may be significant that Scriv3 is more than double the size of Scriv1 - 495MB vs 191MB. It feels like a whole new chunk of code.)

@flange, good ho, and it’s nice to see this moving forwards.

That you have the level of experience you do should be considerable help in sorting this out.

I could suggest a way or two that there could be a Scrivener-unique problem, as @rms wisely suggests, even as you are aware other applications don’t show one.

  • the anti-malware system has decided it didn’t like something during the Scrivener install, so that it’s not present, setting off some chain of error handling which visibly wastes time when it’s attempted often during iniitial file loading. Spell-check could come to mind, which I think is a different package between Scrivener 1 and 3.

  • or similarly, everything is properly installed, but in this case the anti-malware doesn’t like something a package does, which is similarly called often. Let’s imagine, for example, a slient phone-home to check for updated materials that busy spell checker uses; silently each time so that the next will try again, with failure and handling each time on trying to reach the update site.

I would think the first move might be for support to know your PC setup sufficiently, and see if your malware preventer is on the list of known culprits, most at least of which have a whitelisting ability. It may depend on which it is just what you’d need to whitelist, perhaps beyond Scrivener itself.

The drill then woud be to uninstall Scrivener, whitelist in the malware defense, then install Scrivener afresh.

And this could be done even if your malware software doesn’t turnn out to be on the list of knowns, possibly adding to it…

I’m sure you get the gist, and from the little problem model above, also an encouragement about the sorts of things support can draw the design team in on, to discover just what is causing the problem, at a level of detail apropos to resolving it for you and others.

Again, good fortune (or as the British say, good journey, which always felt well to hear…)

1 Like

More specific to Scrivener, and to build off of some of the good system advice above, this is how I would start troubleshooting this:

  • Simplify the inputs. Since the contextual menu for the binder has a lot of potential variability, as it is host to a fair amount of user input. You mentioned the problem persists in multiple projects you use, but I don’t see anything about projects you haven’t used yet. Just create a quick test project using the “Blank” starter, and right-click on Draft. If that is slow, then whatever is going on has nothing to do with the situation the project presents to that menu.
  • If “Blank” is slow: test factory settings with English interface settings, to make sure no preferences you’ve made or localisation bugs are in play. You can back up your settings via the Manage button in the lower left of File ▸ Options..., and reset with the Defaults button to the right of it. Restart the software to ensure all settings take.
    • A number of the tips given above would all relate to this condition as well.
  • If “Blank” is fast, then you’d want to start looking into the sorts of things you can do that change that menu. There shouldn’t be too much that impacts its initial start-up though, that’s interesting. We might for example expect the “Move To” submenu to be a bit slow in projects with thousands upon thousands of menu items (and thus that many thousands of nested menu commands to build on the fly). But it waits until you try to use that menu to build it. But I’m not sure about some of the other menus, they may build on click, so that would be something to look into. For example, opening up Project ▸ Project Settings... in both one of your upgraded projects and the blank test project, and dragging and dropping some label, status, metadata and other settings across, then testing again, we could see if there is maybe an oddity there.
    • While in Project Settings, try temporarily disabling your document template folder, in the Special Folders section, to make sure that isn’t a factor.
    • Custom icons are another potential factor that could be in existing projects. You can test against that by closing the project, navigating to its location in File Explorer, and dragging its Icons subfolder out, reload, and see if its faster. If that helps, try sorting by file size and look for anything unintentionally massive, or of an unusual file format.

To settle a few of these points:

I am led to suspect that the new Windows version 3 was totally rebuilt using none of the version 1 code, but instead ported from the Mac using some sort of intermediate toolkit. I can’t imagine any other way of introducing such an huge delay in basic UI functions. (The fact that fonts are obviously rendered very differently in version 3 tends to confirm this conclusion.)

I couldn’t speak too how much of the core program was rewritten, but an awful lot of it was, that part is true. However the rest is entirely off-base. The original was written in Qt version 4, and this version is Qt 5 (we’ll soon be updating to Qt 6, too). And yes, font rendering is different, particularly on high-res monitors, if that’s a factor.

None of that has anything to do with a Mac, but Qt does represent a somewhat unusual ingredient in the mix, and probably is not used by anything you listed as also having installed. Comparing software performance is not always a matter of comparing complexity, particularly when it comes to anomalous performance issues.

Another thought if have several projects are they all equally sluggish or only one? If only one project create a new one and drag files over and see if works better and if does a project setting issue

In a previous support query, it appeared that you had changed a setting to accommodate other software. Is this the same system, and is it possible that something similar is happening here? Here’s the thread to refresh your memory: Scrivener 3 Trial window unresponsive for over 10 minutes - #4 by flange

Just to say, @flange, looks like we crossed messages here, or wouldn’t have gone on about the anti-malware path…though there are always relatable possibilities.

Three seconds to open a blank page by tapping its binder tag; that’s severe. Has to be some findable reason for that. That’s sort of mechanical hard-drive spin-up territory, it occurs, though probably not usefully.

Or, you have checked the task monitor to see there isn’t a process hog running unexpectedly? Browsers can be, etc… Or memory hog, the same culprit often. But you’d see such delay also on say another word processor to match complexity, up at the same time, as either that or Scrivener tried to swap in from a click.

I should stop imagining now…and I don’t think this guess quite fits what you’ve said, either…

1 Like

I’ve complained about similar here I have issues with Scrivener 3

The lag is truly irritating :confused:

I suggest looking at graphics drivers or Windows updates. It is my understanding the Windows version uses some less common libraries to maintain compatibility with the MacOS version. If you have the option to test with a different graphics driver (e.g. switch to onboard graphics) I suggest you give that a try.

This may sound a little strange, but perhaps installing WSL (Windows Subsystem for Linux) might help.

Other more desperate suggestions: What drive is the project on? Perhaps that drive has some security scanning on it? Maybe the project is on a network drive? Did you do a drive health scan? This might be a sign of impending drive failure.

While keeping drivers and firmware up to date is rarely a bad idea, that wouldn’t be the reason for doing it. There is nothing like that in Scrivener. For the most part the files Scrivener saves are regular old text files, some using XML structure within them to store information, and RTF files. You don’t need any less common libraries to open XML files, nor is that anything special to macOS.

There are a few exceptions that use system-specific file types (archived web pages, shortcuts/aliases), but those are the places where incompatibilities exist between platforms, and no attempts are made to reconcile them at this time.

This may sound a little strange, but perhaps installing WSL (Windows Subsystem for Linux) might help.

Just out of curiosity, what is the line of thinking there? Seeing as how this isn’t something anyone should need to install typically, and most people have no interface lag when right-clicking on the binder, why would this fix a rare case where it does? Doesn’t this mainly just provide enough infrastructure to run *NIX tools, like grep and so forth? How would that help Scrivener, a native Windows program?

I’m ignorant of it though, maybe I’m missing something. I’ve always just installed Linux instead of trying to get that stuff into Windows. :wink: