I’ve been plowing ahead with my grid system redo. Yesterday I got the last vestiges of the old system unplugged from the code and, since this is officially our holiday week, taking the opportunity to clean up some of the peripheral code.
The old code combined the packing of data into the output stream with the actual assembly of the data. Result: spaghetti code mixed with massive blocks of #ifdefs that was utterly unreadable.
What the old code has going for it, perhaps, was efficiency. Hard to judge though. Even giving it the benefit of the doubt, the new code will lend itself to parallelization.
Right now my brain is stewing over how I am going to elegantly/efficiently track (and communicate) changes in such large and complex structures, and in a language that doesn’t have reflection.
Last month, I developed a tool that takes XML input and creates C++ classes with variables that track last-modified time. But I’m not 100% comfortable with the performance for such a dynamic data structure, and each field winds up having a 64-bit timestamp accompanying it.
32-bit timestamps won’t work because the servers can run for more than 49 days, although I could use the vehicle creation timestamp as a baseline, but that means expending CPU cycles to get absolute times.
I could probably get away with 8-bit per-field counters, simply incrementing every field when it is altered, which would allow me to tell what has changed between two viewings fairly easily, and with sufficient granularity. But I then need a way to map fields <-> counters.
I could also “chunk” changes to the data, but we usually perform some translation/reduction of fields in transmission. I’m not sure that chunking wouldn’t result in a significant decrease in bandwidth efficiency. Grr.