[ ] If TravelerList::updated_routes were a TMBitset rather than an unordered_set, would performance increase?
[ ] Remove userlog notifications from store_traveled_segments.cpp & see how much potential headroom there is.
[ ] Would it save RAM? Do the math!
[ ] What about iteration when writing updates to the end of userlogs? If even optimized iteration is too slow, can always maintain a vector alongside.
[ ] All Route objects would need to be in contiguous storage (in this case a TMArray because mutexes).
[ ] Meaning, we need to know the total # of lines in all chopped routes CSV files, sans headers.
[ ] HighwaySystem::route_list could be a new array slice class. Start, length, begin(), end(), voila!
[ ] This could be made compatible with vectors too (where the data (and thus slice) location can change when resized) by storing a reference to another container: begin = parent.data() + offset;
[ ] (Template syntax?)
[ ] TMArray can get a data() member function to enable compatibility.
TravelerList::updated_routeswere aTMBitsetrather than anunordered_set, would performance increase?Routeobjects would need to be in contiguous storage (in this case aTMArraybecause mutexes).HighwaySystem::route_listcould be a new array slice class. Start, length, begin(), end(), voila!begin = parent.data() + offset;TMArraycan get adata()member function to enable compatibility.