[cairo] path storage optimizations ( was: how to propose a change? )

[Behdad Esfahbod]

On Fri, 2007-08-31 at 11:40 -0500, ionous wrote:

> owen and behdad, re: why.
> 
> mostly because i'm interested in how cairo works.  cairo helps fill a 
> void in the game programming world, its license is amenable to usage on 
> game consoles, it's cool stuff!

Sure, we definitely appreciate you hacking on it.  We all have fun doing
it and I'm happy that you have the same feelings.

> the path stuff is nearer to the surface of cairo - and i felt that there 
> was a small bit of optimization that could be eek'd out there.
> 
> while a generalized memory management system for cairo would help out 
> more -- reducing malloc frequency and overall memory usage is important 
> ( most consoles don't have memory page swapping so fragmentation can be 
> a big issue ).

Speaking of malloc reduction, we did a great malloc hunt a few months
ago.  For example, from the release notes:

1.4.2:
• It was Behdad that suggested we focus strictly on bug fixes now that
  we shipped so many performance improvements in 1.4.0, but it was
  also Behdad that got distracted by the chance to remove a lot of
  mallocs from cairo. Paths, gstates, trapezoids, splines, polygons,
  and gradient color stops will now use small, stack-allocated buffers
  in the most common cases rather than calling malloc as
  often. (Behdad Esfahbod). And look for more from Mathias Hasselmann
  soon.

1.4.4:
After 1.4.0, Behdad launched an effort to chase down excessive calls
to malloc within the implementation of cairo. He fixed a lot of
malloc-happy objects for 1.4.2, but one of the worst offenders,
(pixman regions), was left around. Mathias contributed an excellent
series of 15 patches to finish off this effort.

The end result is a cairo that calls malloc much less often than it
did before. Compared to 1.4.2, 55% of the calls to malloc have been
eliminate, (and 60% have been eliminated compared to 1.4.0). Well
done, Mathias!


It was then when merged the op and point bufs in cairo-path-fixed.
Previously it was using separate buffers.

> i'm sure there are much more important bottlenecks around and maybe as i 
> learn more about cairo i can begin to help out with those.

The key is to measure first.


> behdad, re: sizes.
> 
> the macro CAIRO_PATH_BUF_SIZE controls the number of points ( and ops ) 
> in each cairo_path_buf_t.  under gcc ( and your latest patch: vc ) that 
> should be 464/5=51.555 elements yielding a size of 476 bytes for 
> cairo_path_buf_t.  475 in my printout appears to come from a difference 
> in rounding due to the precision toggling i do for mixing d3d and cairo.

Humm, not sure I follow.  Is there anything that needs to be fixed in
the macro you mean?


> at any rate, with the "stable release" code, i see:
> sizeof(cairo_path_buf_t)=476;
> sizeof(cairo_path_fixed_t)=500.
> 
> a math error in my reporting of the gcc totals does make the highwater 
> gcc counts in my former email incorrect.  the original code does much 
> better than i advertised.
> 
> the actual highwater original buffer usage is: 27,396 bytes w/ 46 
> buffers alloced.  the highwater command stream usage is still: 24,176 
> bytes w/ 40 streams alloced.
> 
> so the changes bring only an improvement of 3k and 6 allocs in this case.
>
> all, re: is it worth it?
> 
> i think so.  whether things like a tad fewer allocs and a tad less 
> memory used trump code maintenance is a definitely an important 
> question.  in this case, i think the new code is just different than the 
> old code, not less maintainable.  previously you had to understand the 
> why of checking for flags like "current point" and peeks for "move tos" 
> -- now you have to grok a small state machine, and a null terminated 
> list of draw commands.  neither is particularly problematic, tho both 
> require some thought.
> 
> once i get back from my trip - i will figure out the build issues, make 
> patches against latest, and re-post so y'all can take a closer look-see.
> 
> oh. and sorry about the earlier html emails; still learning my way 
> around thunderbird. ^_^;;
> 
> -io.
> http://www.ionous.net
> 
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759