Performance Discrepancy

In the docs, Tin processing time scales linearly and processes in the order of one million points per second:

Yet, the following code takes ~125s, and playing around with different values for N, performance is very much non-linear.

int N = 1_000_000;
List<Vertex> vertices = new ArrayList<>();
for (int i = 0; i < N; i++) {
	double x = Math.random() * 1000;
	double y = Math.random() * 1000;
	vertices.add(new Vertex(x, y, 0));
}
long tStart = 0;
IIncrementalTin tin = new IncrementalTin();
tStart = System.nanoTime();
tin.add(vertices, null);
long tTinfour = System.nanoTime() - tStart;

10,000 points: ~65ms 100,000 points: ~2.7s 200,000 points: ~9.4s

What’s going on?

[gwlucastrig]

Michael,

I think that you are right that I have to make the recommendation for using the Hilbert sort much more prominent. It’s hard for me to look at this stuff with a fresh perspective, so I was hoping you might have a suggestion. Is there a place in the documentation that I could include the discussion so that it would have the highest probability of a new user finding it?

Also, I did a test where I processed a random number of samples between 1000 and 1 million with samples at random coordinates. It turns out that the best fit for the time-complexity curve for the non-sorted sample set was of O(N^2). The Hilbert sort reduces that to basically O(N) with a small quadratic component.

Non-sorted:

But, sorted, with a much smaller processing time:

I’ve attached a zip file showing the test program. The other thing I would probably try is to include the time-to-sort as part of the processing-time tabulation. Properly speaking, it does contribute to the overall processing time.

TimeComplexity.zip

[gwlucastrig]

Incidentally, I was looking through my Tinfour test project in Netbeans to pick a good place to store your test program, and I realized I have a package called test.micycle1. I think that’s a good tribute. Thanks for sending me so many interesting questions over the last few years.

Gary