Lag in traceback

[controversial]

In very large networks, the traceback can sometimes be very slow. The whole network pauses during slow tracebacks.

A hackish solution could be to call traceBack asynchronously from a setTimeout call, which might not freeze the network in the same way. However, this would address the symptoms rather than the problem, and not actually improve the speed.

A much better solution would be to increase speed by reducing the number of iterations that are made through the traceback nodes. Right now, 6 iterations are made:

1. Iterate through parents to identify traceback nodes
2. Iterate through identified nodes to adjust color
3. Iterate through identified nodes again inside vis.DataSet.update
4. Iterate through parents to identify traceback edges
5. Iterate through identified edges to adjust color
6. Iterate through the edges again inside vis.DataSet.update

Looking into the code for vis.DataSet.update, it appears that commit dfc633e was made in error. This added two more iterations to the list, further slowing down the traceback, rather than speeding it up.

To bring this down to one loop, traceBack, getTraceBackNodes, and getTraceBackEdges could be merged into a single function with one iteration. nodes.update() and edges.update() could be called once for each item as they are identified and modified. This could bring the total loops made through the same data during a traceBack down to one.