compute_stats_r branching micro-optimizations if bored

[yakra]

Not user stats but stats in general. But anyway... https://github.com/yakra/DataProcessing/blob/7fb4d73e8bde139dbb5a46c970ea932429a63ec7/siteupdate/cplusplus/classes/Route/compute_stats_r.cpp#L37-L40

With just some {}s & indentation, we can fold the if (system->active()) check into the if (system->active_or_preview()) block and save extraneous checks. If not active_or_preview(), we know it's not active().

Better yet? Replacing the whole thing with a switch makes things readable enough that we can lose the comments. Much cleaner. There should be fewer conditionals under the hood:

• p passes case 'a' & arrives @ case 'p'. Same as calling active_or_preview().
• a goes from 2 checks (active_or_preview() & again @ active()) to 1, with the a/p operations done via the magic of fall-thru.

Yet this appears to be running slower. Why? Is it just noise in the data? Become bored & test with a bigger data set.

• [x] customize code:
  • [x] terminate after compute_stats_r
  • [x] get rid of unnecessary steps before, e.g. .list files or NMPs? This could have cache effects; such has been observed before... But sure why not. It should affect all variants equally.
  • [x] insert an artificial loop so the changed bits get repeated loads of time, magnifying the delta
• [x] all thread counts
• [x] ~100~ 50 reps or ~more~ sometimes 10 in check10.sh

Hidden systems? Once accounting for hidden systems, we're winning a little more with brevity & readability. Don't need to add if (system->level == 'h') continue; or anything, just change default to case 'd'. Might even end up being faster too; we avoid an extra test for a/p systems.

Earlier code: https://github.com/yakra/DataProcessing/blob/7fb4d73e8bde139dbb5a46c970ea932429a63ec7/siteupdate/cplusplus/classes/Route/compute_stats_r.cpp#L13-L22 Some or all of these ideas may or may not be good ones, or make it to production

• [x] rewrite as switch (again, think forward to hidden systems)
• ~lose the other != s check; init concurrency counts to 0 (stashed && other->route->system->level != 'h' is combined here)~ Nope, Would have the same number of conditionals at minimum.
• ~increment other, not just s; skip calculating segments already computed based on another~ Nope. Would need some way of tracking whether active & a/p miles have been added, and most to-the-point, miles for each system involved. Current fractional way of doing things is as good a method as any.

[yakra]

prelim rankings before bumping up the reps n'at

BT 1st pass .1633 .1611 .1636

box	-t 4	-t 1	comments
BT1pass	102	!
BT2pass	120	210
lab1	021	021
lab2	021	021
lab3	201	012
lab4	012	102	(redo 2, due to SCPing files partway thru?)
lab5	0(tie)	120
bsdlab	210	210