I have found that adding more worker threads in Windows 7 has helped improve the performance, particularly on start up. Estimating that it is a third better, i.e. if it took 30 seconds it now takes 20 seconds.
Showing thumbnails has nothing to with memory. It is almost entirely based on disk speed.
Your catalog file and previews ought to be on your fastest disk. What disks do you have on your system, what are their speeds, and what disk contains the catalog file and preview cache?
Catalog, previews are all on the fastest SSD (M.2-500GB) I have. It was still slow. Program disk is another SSD. Photos on a raid5 supporting NCQ with buffered reads and writes, blocksize 256K
Adding the worker threads has made quite a difference, I can now drive the CPU at 40% to 60% utilization when I am in develop.
The load time for thumbnails is almost instantaneous, even on medium to large directories. I have a 14,000 item smart collection and that took about 15 seconds for thumbnails, so all in all much faster with more worker threads. (if you try adding threads, make sure that you have enough resources (cpu & memory)).
LR is running 78-79 threads. Windows worker threads totaled 26 before, now at 56
How does one add worker threads?
Thanks for the link!
I take it you were playing with the "AdditionalDelayedWorkerThreads"?
I increased both critical and delayed worker threads. I up'd the numbers again, and again got a performance boost. The system is now performing more like how I thought it should.
I'm surprised at the poor performance that you describe. I use a fast desktop (3ssds, 1Hdd, 32GB ram, 6/12 core cpu, x99 mobo, Win10) and don't normally have any such problems. LR (CC2015.1.1) opens quickly, the no's fill in faster than I can look at them, and the screen fills with images almost instantly (provided I have made previews for all the images).
IME, and I've been using LR since version 1, the sort of symptoms you are describing are usually due to corruption somewhere in the previews themselves, the previews.db, or the root-pixels.db. The acr cache isn't used much, so is unlikely to be involved in your problem. The cure, IME, is to delete all the previews, previews.db and rootpixels.db, and regenerate new ones. If you are doing this, also purge the acr cache as it will make new dat files when it creates the new previews.
As it happens, I'm in the middle of doing this with my 100K nefs, a day and a half gone and another to go before it finishes. I make all standard previews first, and then only make the 1:1s that I need. Since the 1.1 update, LR now takes about 5 secs for a 1:1 preview for a big 36Mp nef, and 1-2 secs for the smaller ones. Standard previews are quicker. I'm doing this because I noticed a bit of a slowdown (nothing like yours) in filling the screen with images the other day, and thought "right, it's time to redo the previews." I probably redo them every six months or so. When I do this I usually also delete the old Prefs file and start afresh with a new one. So I just keep my catalog and settings stored alongside the catalog.
Writing stuff out to xmp is a known time-waster, so I don't do that. There are quite enough other background tasks going on in LR without that one taking up more resources.
I looked at your extra threads stuff and decided I didn't need to go there! When just LR is running making previews, it uses about 6GB of ram, there are 1300 threads in existence, and it uses 25% - 50% of my cpu (up to 100% if I turn off hyperthreading).
Hope this might help.