On Tue, 16 Nov 2004, Bryce Harrington wrote:
This approach is consistent with Cairo, which is even more attentive to correctness (and correspondingly has similar performance concerns.)
I actually suspect that even current versions of Cairo, used carefully, should prove faster than the livarot-based renderer.
to implement a number of new features. The renderer's performance is not as optimized as Sodipodi's, however. We suspect this is not because the renderer cannot be optimized but rather simply because there has not been a sufficient amount of attention placed on optimization.
The livarot-based renderer currently performs a lot of transformations on the rendered paths that aren't necessary for simple rasterization (for example, uncrossing and rewinding self-intersecting paths) -- that's probably the biggest area to attack there, while we still use it.
In some cases, there are tradeoffs between features and performance; sometimes a really handy feature can only be obtained by adding code that will impose some slowdown in performance.
I don't think any of the most significant performance issues represent feature tradeoffs at this time.
Perhaps for 0.41 we could establish some performance improvement goals, like we've been able to do so well with bug count? E.g., select a few test conditions and aim to improve the total performance on those tests by 15% or something?
I think 200% improvement is would be the minimum reasonable goal, if we were to take a benchmark-based approach.
Micro-optimizations that yield ~15% improvements are easy to do (given a profiler), but they tend to mangle code in ways that obscure the patterns that can be exploited to yield order-of-magnitude improvements (through the use of a better algorithm for example).
That's not to say some smaller-scale optimizations aren't worthwhile. As you experienced when you were rewriting some of the if-cascades in livarot, simplification of code can have measurable (if not always order-of-magnitude) performance benefits.
-mental