| QUOTE (lignumaqua @ July 20, 2013 01:30 am) |
| A couple of random thoughts: 1. maccamob - I know you already said that you had excluded GSAK from live AV scanning, but can you confirm that you are excluding the GSAK AppData folder where the databases are, not just the program folder? It's the database scanning that really slows things down. 2. How about cloud services such as Dropbox? Are any of them synching your databases? |
Thanks. Yes, I have excluded the AppData folder and, although I do use Dropbox, I don't use it for any GSAK purposes. hynr's post got me thinking a bit, although I haven't yet tried out the suggestions.
When I copy my daily finds/DNFs, I am effectively adding new caches to my default database. The same thing happens when I add my weekly PQs. I just ran one PQ covering the most recent placed dates. It added 62 new waypoints and updated a further 497. The process, from adding the gpx file (but not including the time to download it), displaying and dismissing the change summary, and the grid then appearing was only about 20 seconds.
The copied found/dnf caches are generally established caches and are likely to have more logs included than the new ones from the PQ, but to offset that, the 497 caches updated from the PQ will also have new logs. So I conclude that the PQ process is significantly faster than copying from another database.
Wouldn't GSAK have to do the same "housekeeping tasks than need to be done (updating log counts, distance recalculation, etc)" noted by Clyde whether the new or updated caches come via a copy from another database or from a PQ? If not, might the difference(s) explain the grid delays I am seeing after copying?