Quick version: I implemented a huge efficiency improvement in the site update process today that is only barely tested so far. I'm going to use it for tonight's site update, and it's definitely possible there will be mistakes. Once it runs, I'll post here and people can make sure things look ok.
Longer version: As our highway data and number of lines in user list files has grown, the initial brute force matching that worked well enough when I first implemented TM has become a bottleneck in the site update process. For last night's update, that part of the process alone ran for 22 minutes. I've thought for quite a while that this was screaming out for a hash table, so I finally put one in today. The trial update I ran (but did not install on site) took 17 seconds to perform that part of the update process! Some error log messages changed slightly but I think there should be no other changes visible from the site user's perspective. Of course, I might have broken something. The only change is in the detection of the clinched segments on each route for each user (in other words, the whole reason people use the site), so a bug here could mean everything's a mess. If it looks bad, I can easily enough revert to the old update code until I can debug.
