It seems that this has already been mentioned by others, but today this bug is still present.
The outliner is REALLY slow if you have lot of files (eg. 200+). It is so slow that on slower machines it hangs completely. On the other hand, the very same word count opened by Word works at lightning speed (just to point out is not an hardware fault).
Word is a false comparison, since a Word document is a single file, where your Scrivener project with 200 documents is a folder with 200 separate files for those documents, plus a lot of other supporting files.
That is not to belittle your problem, just to highlight an important difference.
Mark
I can confirm it.
I have a project with over 350 items in the binder. It hangs even if the synopsis is hidden in the Outline view. In the given example it took around three and a half minutes to open the Outline view without the synopsis.
I agree with xiamenese about Word though.
Regards,
M
Try File > “Save and Rebuild Indexes”, Close and reopen the project. This might speed up things, as some data will be pulled from the internal database and avoid loading the files from the HDD. Hope this helps.
How organized is your project? If it’s a bunch of documents in a manuscript with no folders, slowdown is expectable (https://forum.literatureandlatte.com/t/not-responding/44088/5).
On the other hand, even adding just one level of separation between Manuscript and documents helps immensely.
(https://forum.literatureandlatte.com/t/speed-with-lots-of-documents/45872/1)
On Beta 36 and the problem is still there.
I understand that a lot of files could slow down the view, but the same amount of files are displayed fine on a corckboard view. To be, there is something wrong on how the outline is built.
Maybe Scrivener should fetch data only for items displayed in the list view, instead of fetching EVERY SINGLE PIECE OF DATA at one time.
Just my 2 cents
Except the two systems are entirely different. The outline view allows you to pull down a list and choose from perhaps 20 or so columns AND even custom fields for the list view. Furthermore, they intend to allow sorting by each of the columns (when they get that working). That will include sorting by date eventually. So a table needs to be built in memory with different elements and manipulated, not by drag and drop, but by sorting on any column.
I agree, that they should be able to handle more stuff, but it is very different from the simpler corkboard view.
Version: 2.9.0.44 Beta (876128) 64-bit - 26 Mar 2020
This problem definitely still exists. I only have 95 documents under my manuscript folder and it takes many seconds (20-30, at least) to re-render any time I open the outline, or make any changes to the columns including adjusting width.
By comparison, the older (1.29 or whatever it is) version was nearly instant (maybe some lag on occasion, but 1-5 seconds, tolerable), with exactly the same setup. All I did was copy my document to the beta and started having the issue.
We believe this has been fixed and the fix will be available in the next beta 45. Give it a spin and let us know, once you test it.
Cool, thanks. I will take a look when it comes out.