This problem has been around for some time I think - I've mentioned it previously but can't find that thread.
I make a folder of many thousand 40MB nef raws without any edits (or use reset to clear edits) and set LR 2015.8 to create 1:1 previews for all of them.
It starts off (on my fast desktop Win10, i7 K5930, 32GB Ram, 3ssds (for system, cat&previews, and caches), 2 HDDs (for nefs), and a M2000 Quadro GPU) at about 3 secs per nef, watching Task Manager cpu etc. If I leave it for the appropriate number of hours to complete, I find it hasn't completed and is now taking about double the time per nef. If I do this with edited nefs, they start off at about 7-8 secs per nef, and increase to 16-20secs!!
Closing LR and rebooting sets the rendering speed back to the start time; closing LR alone has no effect - rendering is still the same as when it was closed. So something is remembering that it has to run slowly!! That led me to think about the Standby memory which after a while occupies almost all of the 32 GB (as it should if Windows is working correctly).
Closing LR and rebooting clears both the In Use memory and the Standby memory of LR's stuff. Closing LR clears the In Use memory but not the Standby memory, so what could be in the Standby Memory that LR picks up when I reopen LR? Not being a programmer, I was quite surprised to see what is stored in Standby. Using RAMMAP, one of MS's SysInternals utilities, I could see the list of file stored in the Standby memory. Quite amazing to me that every file that LR has used in the past session is stored there in case it is wanted again; all the nefs, previews, cache file, temp files, catalog, etc, etc, as well as system files.
RAMMAP also lets you clear all those files, even while LR is running. But that does not set rendering speed back to normal, presumably because the problem is not only in the Standby memory but also in the In Use memory. Only clearing all memory of LR traces by rebooting or by using RAMMAP after closing LR gets rid of the problem. The latter is quicker than rebooting, so something useful has come out of my play!
But it would be a nice New Year's present if the programmers at Adobe could eliminate the cause!
I've no idea if this problem is linked to the slowdown in editing with time that others report. Maybe I suppose.