runtime: Double.CompareTo() performance hurt by not being inlined

I was profiling some Paint.NET code in WPA the other day and noticed that Double.CompareTo() was taking a non-trivial amount of the execution time:

The scenario here in the app is to select an area of the canvas (Rectangle Select, Ellipse Select, Magic Wand, whatever), switch to the Move Selected Pixels too, and do some transforms on it (rotate, scale, etc.).

The selection is represented by a poly-polygon (IReadOnlyList<Point2Double[]>) which is then scan-converted into an alpha mask (bitmap). Scan-conversion is the standard algorithm for doing this and involves lots of sorting, at one point by Y values and then repeatedly by X values. Double.CompareTo() is used quite a bit here, in other words. In the screenshot, you can see that the most time is spent in 1) filling an alpha mask bitmap from the list of scans/rectangles from the scan-conversion code (MaskFromScansRenderer) (this code is vectorized quite a bit now, lots of buffer filling), 2) rendering the transformed pixels onto the current layer’s bitmap (TransformedNearestNeighborContentRenderer), 3) some other rendering/compositing and hit-testing (MoveToolContentRenderer), then 4) System.Double::CompareTo() (!!!), and then most of the rest is the actual scan-conversion, sorting, and some more buffer copying.

To investigate further, I crafted up a toy benchmark in LINQPad where I timed how long it took to sort an array of 10 million randomly generated doubles (10 iterations per benchmark). All the usual perf tricks were employed, including pointers to elide bounds checks, and an optimized copy of Sort<T, TList, TComparer>() where everything is structs, interfaces, and tagged with AggressiveInlining. For the first benchmark, the stock Double.CompareTo() is used, and for the second benchmark a copy of it with [MethodImpl(MethodImplOptions.AggressiveInlining)] is employed:

My results:

(you can ignore the CompareNoNaN result, it was just for fun to see what happens if I remove the branches that test for NaN)

More than twice as fast – indicating that the overhead of not inlining Double.CompareTo() is substantial.

My hypothesis here is that adding [MethodImpl(MethodImplOptions.AggressiveInlining)] to Double.CompareTo() (and probably Single.CompareTo()) would be an easy and impactful win. I suspect that these methods aren’t used extensively throughout the runtime or other codebases, so the codegen size impact should be small, and where they are used the performance gain would be worth it.

I’m happy to craft up a proper benchmark with real data that others can inspect. I’m submitting this issue so I stop procrastinating on it 😃

cc @EgorBo, @tannergooding , who were part of the conversation about this on Discord #lowlevel