Scrivener performance on viewing multiple files

Overall, the performance of the binder has continued to improve through the recent betas. The one exception seems to be with ‘Scrivlings mode’ (I think it’s called that or otherwise the whole document view mode). With a large project, such as 65 folder chapters and about 85 total sub documents totaling 260k words, when I try to view the whole thing together as one document, it literally overwhelms my computer for a half hour or more until I eventually kill Scrivener. Now my computer isn’t the speediest, but there is clearly something wrong with what I’m seeing here.

One thing that would help would be for Scrivener to either respect the Esc key more readily, or whenever performing a potentially large operation, offer some way to cancel it so it doesn’t kill everything if things get out of hand. I’m curious to know what other people are seeing when viewing large projects as a whole.

sounds like an important issue to be still worked, if more people have it.

I just tried a document with about 80 segments and about 80,000 characters, and it took 5 seconds to bring it up in this combined-edit mode.

That’s quite reasonable. When I made a change in combined editor, then went somewhere else and searched for the change, this was quick. However, the found change was shown in the individual segment.

This meant the 5 seconds again switching back to combined-edit; more importantly, the combined-edit didn’t return to the point of changes, so I had to scroll down to get to that again, which could be problematic as document size or complexity grew. I would vote for the combined view to scroll to the last-edited-or-viewed point, on that score.

As always, hoping the feedback helps the team.

Regards,
Clive

Half an hour to load is a bit extreme, yes. Any additional specs would be helpful, e.g. from Lee’s list on How to Report an Issue Related to Performance:

As far as the second point on switching in and out of Scrivenings, each Scrivenings session is unique, so the program doesn’t have any way to remember where you were or what you last did once you’ve closed the session. The way to do something like this–run a search and check a document while you still have a large session open–is to use the split screen and load the single document in the other editor. You can lock the editor (Ctrl-Alt-L) on the Scrivenings session as well to help avoid accidentally clicking out of it.

Ok, here’s what I have so far:

Recipe for Click-O-Death

1 Laptop including:

1.6ghz Pentium M (no laughing, please! :blush: )
1.5 GB Ram
120GB HD w/12GB Free

1 Scrivener Project including:

64 chapter folders
~85 text scenes
260k words
total project files size = 4.18MB
total files: 389
Total folders: 8

Instructions:
To achieve the Click-O-Death, start scrivener (doesn’t matter if first time this session or not) and open said project. Click on top level folder. Click ‘Scrivelings’ button.

I did notice some interesting things this last time I tested. I had Scrivener and task manager side by side when I did this and here were the results:

pre click-o-death: Scrivener negligible CPU usage
pre click-o-death: Scrivener memory working set: 28MB
after click-o-death activated:CPU < 10% (often 0-1%)
after click-o-death activated: Constant Disk Activity
after click-o-death activated: scrivener memory set:
[list]slowly climbs up to 1.2GB and stays there for 5-10 minutes
Then drops down to about 500mb for a few minutes
Then climbs back up to about 1.2GB and stays there until eventually scrivling is deisplayed
Then levels off at about 800MB until another document is clicked on to open it.[/list:u]

Hope this helps! I may try monitoring Scriveners file activity next to see if that sheds any more light on the issue.

Excessive memory usage definitely seems to be an important clue here. With 1.5GB total installed in your machine, if it climbs up to anywhere near that during a process, you’ll be getting a ton of swap activity as Windows switches to using more virtual memory to continue running the operating system and any other programs you are running, including Scrivener. That would be the excessive disk usage you note as well. Virtual memory is inferior in speed to real RAM, and the whole computer should become sluggish to use while heavy VM is in use. Does all of that sound about right?

Hmm. Well, I tried the line you seem to be proposing, Mouton.

I think what I should do is wait until things are a bit more developed around these aspects, especially as I don’t know how the Mac version functions, and then see what’s worth commenting.

I did note:

  • the search box and what you wrote in it remains when you switch to the Scrivenings split. Although it’s not affecting it at that point.
  • in fact, ‘locking’ a split still has it trying to follow the search if you change that, except it doesn’t find anything and changed the ‘locked’ split to just show in block letters ‘Draft’. You could get the Scrivenings full view back by clicking on the binder Draft folder again, but starting at its beginning instead of where you were.
  • the locked split still was showing the search results and no Binder to click on - is the multiple view just missing in this release? If you closed this Search Results view, the Binder was back but not affecting the locked editor - probably as it is intended.

I would lightly propose, with above issues acting better alone and in concert:

  • Scrivenings sessions really ought to track clicks on the binder – jumping to the clicked scrivening seems very logical, useful, and expected, don’t you think? This would at least cover a lot of territory if you don’t feel to do more. A writer could for instance search in the top pane, and be able to go to the area of the finds.
  • Not sure what you mean by ‘sessions’, but it should always be possible to pass back a notion of where you have been, and use that to get smooth passage for people writing, which is what I comment for (and only for) in the forum.

Regards,
Clive

p.s.

  • turning back on View>Show Collections also got me the Binder showing when Search Results were present, on the two editors view (not going through all the permuted combinations here). Shouldn’t be necessary to have that on, though.

  • presuming having lost all preferences on this install was a one-time occurrence. We live in hope…

  • noticing the flippy switch at upper left of lower editor, found I could get back to another state which was not Scrivenings total, but when switched back had also lost the Locked red tint, so presume locking was gone too. Also, result of search (big Draft showing only) was still there. Am sure this will all sort out when there’s time to look at it.

Regards, and there you go,
Clive

p.p.s. I am (honestly) really enjoying all the colo[u]rs :wink:

Hi Clive,

All right, the behavior I outlined is what should happen. Unfortunately, as you discovered, there appear to be some bugs with this. So…it’s all logged now. Heh.

What should happen: The search term should remain and if the term is found within the Scrivenings session, you should be able to use find next/previous to jump to those places in the session. It should not lose your session or jump anywhere automatically.

Right, that’s all wrong. Clicking anywhere in the binder shouldn’t affect the locked Scrivenings unless the document is in the session, in which case it should jump you to the start of that document while still keeping you in the session.

Not totally clear on this one; could you rephrase? By “multiple view” do you mean seeing the different tabs? If so, you need to click on the “Collections” button to view them; search results is a collection and it will automatically load when you run a search and close if you cancel the search, but it is possible to just switch to the binder or another collection without canceling the search so you can easily hop back to it and still have your search term remembered. (You can also click the “x” in the Search Results header bar in the binder to close the search collection and return to the regular binder; it will still save your search term until you change it.)

Hm, I was unclear and maybe misunderstood what you were doing. If you use the document history button in the editor to return to your previous Scrivenings session, then yes, it would be nice to have Scrivener jump to where you were last viewing, similar to how it remembers where you were working in an individual document. That should be coming; the difficulty is that what you’re viewing as a single document is of course actually made up of several disparate pieces. Pre-2.0 on the Mac, actually, it wasn’t even possible to use the back button to restore the session. So the Windows version is already one up on that, and when Lee gets to do further refinements on Scrivenings session post release, he’ll be able to take a look at this.

Yes, using the forward/backward in document history buttons will take you out of the locked state. Locking is really so that you don’t accidentally click in the binder and load a document you didn’t mean to, but using the forward/back buttons is a fairly intentional action so it’s assumed if you do that you really mean it, and thus the editor unlocks for you.

Yea, it’s definitely an excessive memory issue. I was quite surprised to see the number climb that high and the computer does become basically unusable until I either kill scrivener or patiently wait for it to finally finish and then switch off Scrivelings. I’d be curious to see what usage levels people with a lot more RAM experience on larger projects. It could be if there was more RAM it would not croak like this, but I can’t see a reason it should need this much memory for what it’s doing when the total files are only 4mb

Hi Jennifer,

As far as I can see, we’re on the same page in nearly all you said, and you’ll find I’m quite in tune with the notion of ‘how things develop’ per ‘how things should be’. Thanks for laying out a lot of that.

The one thing we can get clearer on is a bug that probably ought to get nailed early. The compound of it is:

– 024 installing apparently zaps preferences, and/or remembrance of user interface state. Whatever it is that’s affecting this case, the key is that menu ‘View>Collections>Show Collections’ was no longer turned on for me.

– With Show Collections not on, that’s the case where you now in 024 also don’t see the Binder as a label option in the Binder column, once a Search is up.

  • Only the Search you’ve just made shows: no other layers in that unique and effective UI item at the top of the Binder column.

  • Turn on Show Collections, and then the real Binder is back being visible on its layer in the widget, along with any Collections and the Search on theirs, as should be – and now with colors. This issue at least should be corrected. I don’t think it happened before.

That’s the post-midnight version from here, so let me know if I need to be yet more clear, when capable :wink:.

Best,
Clive