Monday, April 24, 2006

more optimizations

In Draw:
replaced CRect::OffsetRect in Bounds calc with inline
replaced CRect::PtInPect in inner loop with inline (BIG difference)
only calculate iorg if making Curves

hot rod, 1024 x 768, maximized (but not full screen)
default patch, fill & outline, speed = 20 "curve fill bench.whl"
total Draw time for 1000 frames at 25 FPS, in seconds
average ring count = 193

v1.1.01 v1.4.04
12.643 12.831
12.630 12.641
12.629 12.639
12.629 12.830
12.638 12.651
12.633 12.638
12.637 12.833
12.636 12.645
12.630 12.840

12.634 12.698

1.4.04 has a noticeably larger deviation: most of the samples cluster around 12.64 but every fourth sample or so clusters around 12.83. No idea why! Generally the results are encouraging however. If we go by the averages, 1.4.04 is 64 microseconds slower per frame, which translates to an extra 1.6 milliseconds per second at 25 FPS. If we go by the worst case, 1.4.04 is 210 microseconds slower per frame, i.e. an extra 5.25 milliseconds per second (half a percent). Neither difference is likely to be significant.

Same exact test but without fill (still on hot rod):
v1.1.01 v1.4.04
0.428 0.413
0.428 0.413

For non-fill case, 1.4.04 is FASTER! Awesome. Presumably inlining PtInRect in the innermost loop made the big difference, let's see.

1.4.04 no fill, using CRect::PtInRect:

Yup, CRect::PtInRect was bad stuff. Not sure whether it was the function call or inefficiency within PtInRect itself, or maybe both.

An interesting question: why is the difference worse with fill/outline? Almost all of the added code gets executed regardless of draw mode. The only exceptions are the Convex test to decide rp.Color vs. PrevColor, and the (Curve || PrevCurve) test. Surely these can't account for 64..210 microseconds per frame?

No comments: