We calculate bounded areas - the boundaries are given in latitude/longitude ie, 48.5 deg N to 48.8 deg N, 105 deg W to 105.2 deg W. The bounded area is approximately the area of a trapezoid, except at the North Pole. The problem is 'approximately', as it gets more/less approximate as latitude changes. If the quadrilateral is small enough and not too far North,we just pretend it's square and go on.

The problem comes for larger ones or one in the far North.

Breaking the large area up into really short trapezoids, gets more accurate results. No surprise. We need accuracy circa 1:10000.
I can test for that. Run several tests using smaller trapezoids until we get where we want to be, or results do not change. This means a lot of extra cpu cycles.

The problem is performance. We do several million of these a day, and they are part of real-time data acquistion. I cannot waste time narrowing down the best approximation. I need to jump in at the reasonable level from the get-go. Right now we have a bunch of data in tables and have lookups that return heuristics. Works. Too much overhead (i/o on remote Oracle kernel is too slow)

Here is some dummy sample data to show you:
The red lines are the point where we got reasonably close to a decent result. They good result point can be different, but you can't tell a priori where it will be. I can't anyway.

from 0 to 5, 0.10 wide
stepsize:1.00000 area:34389.4801
stepsize:0.10000 area:35075.3246
stepsize:0.01000 area:34459.6559
stepsize:0.00100 area:34391.2357
stepsize:0.00010 area:34391.2357

from 5 to 10, 0.10 wide
stepsize:1.00000 area:33856.3562
stepsize:0.10000 area:34526.3349
stepsize:0.01000 area:33924.9792
stepsize:0.00100 area:33864.8234
stepsize:0.00010 area:33858.8076

from 15 to 20, 0.10 wide
stepsize:1.00000 area:31307.5109
stepsize:0.10000 area:31308.4049
stepsize:0.01000 area:31308.4238
stepsize:0.00100 area:31308.4240
stepsize:0.00010 area:31309.0321

from 20 to 25, 0.10 wide
stepsize:1.00000 area:29367.1160
stepsize:0.10000 area:29369.1078
stepsize:0.01000 area:29369.1277
stepsize:0.00100 area:29369.1279
stepsize:0.00010 area:29369.6933

from 85 to 90, 0.10 wide
stepsize:1.00000 area:75.1336
stepsize:0.10000 area:78.6199
stepsize:0.01000 area:78.6441
stepsize:0.00100 area:78.6444
stepsize:0.00010 area:78.6444

As you can see, it's not necessarily predictable, as far as I can tell.
Does anyone know of a non-exhaustive approach that will provide
a quick, good guess as to the best choice for "stepsize" - the height of the small trapezoids?

Human-friendly versions of the two c modules that do this are embedded in a file i/o routine to make the above junk data. It's attached. The code actually stays memory-resident on a unix box, gets data from all over, talks to Oracle, generates areas, and sends it to somebody else. Did not include all that.

And the actual modules use inlining & ASM. Of course, I've profiled them for best performance.