NMP speed improvements

[yakra]

C++

Two components here:

• CloseWaypointQuadtree::near_miss_waypoints yakra/DataProcessing#157
  Don't create a bunch of temporaries and muck about with move constructors & splicing; just push points directly to the nmp list in the Waypoint object itself. Saves a rather surprising amount of time for what it is.
  
• CloseSingle-threaded NMP detection: restore Jim's original formula #457
  When no-mutex NMPs #280 were enabled, multi-threaded NMP searching came at the cost of a performance hit in single-threaded searches. Background is at idea: replace per-point NMP lists with a method #141.
  Conditioning Jim's original formula back in for single-threaded siteupdateST is easy.
  Speed comparison after the above component, constructing in place:
  • Time no longer spent specifically Searching for near-miss points via Eric's method should outweigh
  • the additional time Reading waypoints for all routes, which represents Jim's method.

    Box	Eric’s	Jim’s
    BT	1.72	1.437
    lab1	1.009	0.6198
    lab5	1.435	1.033
    lab2	1.349	0.966
    lab3	1.79	1.092
    lab4	2.16	1.601
    bsdlab	2.581	1.752

• A third component I tried out & rejected was to
  

  DataProcessing/siteupdate/cplusplus/classes/Waypoint/Waypoint.cpp

  Line 219 in de796fa

  { // sort the near miss points for consistent ordering to facilitate NMP FP marking

  in NmpSearchThread rather than a single-threaded part of the program. Turns out this is slower.
  What can I come up with for an explanation?
  • Turning cache hits into cache misses -- the single-threaded bit already deals with root & label.
  • Branch prediction effects, whether sorting is done at the same time as iterating down through the quadtree.

---

Python?

Python OTOH has kept Jim's original "search a partially populated quadtree while reading all waypoints" NMP method the whole time. The only thing to do here is to try out building the NMP lists directly in the Waypoint object.
We're still creating and copying (not moving, I presume?) from a bunch of temporaries, right? I'd expect better results than:

Box	de796fa	a768800
epoch	115.24	120.19
BT	113.3	111.59
lab1	56.98	57.07
lab5	51.18	51
lab2	72.24	72.09
lab3	98.15	97.2
lab4	80.26	79.61
bsdlab	126.58	125.06
noreaster	93.46	92.53

Python is pretty mysterious under the hood. Maybe it has to check whether w.near_miss_points has an append method every time when attempting to call it, and OTOH knows that locally-declared near_miss_points is a list? I don't know man, I didn't do it.

I'm undecided about whether to include this. Sometimes I like to make Python changes that mirror C++ changes, just to keep the two versions structured similarly. Other times I'll leave out changes with no clear benefit, to have a smaller impact on the commit history. Is there a clear benefit here? *Shrug.* At least we're down 14 lines of code?
The diff is at a768800. @jteresco, say the word and I can push it to this branch. Or leave it out.

[jteresco]

I'm comfortable with whatever you decide on the Python code. But based on a quick read of your explanation, it would make sense to me to include the Python change also.

[yakra]

Sounds good. Let's save those 14 lines of code, and that 0.93s when running datacheck.sh!
Pushed a768800 to this branch.

[jteresco]

This will be used for tonight's update.