| QUOTE (hynr @ August 20, 2013 03:25 am) |
| I believe that KT is probably right. Many AV systems do not fully change their behavior right away with out a reboot and some other modifications. But if it is ruled out, then: maccamob, Are you doing this without a backup?!? If not, why are you hesitant to try purging logs? You can get them all back once we find out what the problem is. We can't help you if you don't try all the things we suggest. I also see you "waving off" the suggestion that the highlights might be part of the problem. Did you actually disable the highlights (it's a simple checkbox) to see how much difference it makes? It is not a matter of "whether", but how much. Did you use Windows Defragmentation tool as I suggested? I also don't see mention of having done the most obvious step in GSAK: Database => Repair/Defrag. Does the same delay happen if you do this with a macro? Assuming that this is the case, can you insert timer code into this so we can get quantitative information as to what is helping and what is doing nothing? (Do show us that macro). Does the same delay happen if you copy your entire database to a new database and run tests on that new database instead of your old one? Assuming you have the timer suggestions working, what is the number of seconds delay that it reports. If you delete half of the caches in this temporary database, run Repair/Defrag on this, is the delay cut in half? On Tools=> Options => Advanced => change the checkbox for Interrogate Logs for Found/DNF and tell us how many seconds difference it makes. |
Thanks again for all the suggestions. I'll try to cover them all. First, I have my laptop set to do a hard drive defrag weekly, and it rarely gets above 1% fragmentation in between. I also use GSAK's Repair/Defrag from time to time, and have done so several times since this issue arose. My macro expertise extends only to installing and using them, so I haven't been using one for the copy task.
Tonight I had 34 finds to add, so I first did a full database backup and yet another database defrag with a view to trying out the logs purge that hynr suggested. To set up some sort of baseline I did the usual copy of the 34 caches (plus user notes) after finishing the upload of all the logs. I was surprised to find that the problem seems to have diminished considerably (at least for now), as the resulting time for the default grid to reappear was only 24 seconds (by stop watch). To check Kai Team's suggestion, I restarted the laptop in Safe Mode (with networking), restored the default database to the pre-copy state and redid the copy. The default grid reappeared in about the same time at 25 seconds.
Those times are still a bit long according to Clyde's earlier post, but I could live with that. However, I next restored the default database to the pre-copy state again and purged all but 10 logs on each cache (I had many more on most Australian caches). This time, the default grid took only 10 seconds to appear. It certainly seems that the number of logs is a significant factor.
Regarding ian-and-penny's suggestion, my database properties show that the Smart Name Length is set to "Use Config", which in turn is set to 8.
I'm not sure why the (unpurged) times have suddenly improved, as I can't think of anything that has changed. I have updated GSAK several times along the way (now using 8.3.1.45), but doubt that is significant.
To repeat - many thanks to all for your suggestions.