[cairo] path storage optimizations ( was: how to propose a change? )
behdad at behdad.org
Thu Aug 30 15:34:11 PDT 2007
On Thu, 2007-08-30 at 16:04 -0400, Carl Worth wrote:
> On Thu, 30 Aug 2007 14:12:56 -0500, ionous wrote:
> > I have a version of the optimizations I described up and running now -
> Hello again!
> First off, thank you very much for going back to non-HTML mail. That's
> really appreciated, (it's quite hard for me to not just delete HTML
> mail unread).
> > I've had some problems getting the very latest source ( pixman in
> > particular, but also some minor stuff with the tests ) compiling under
> > windows ( both vc and cygwin/gcc ) -- I will detail and ask for help in
> > a separate mail.
> Thanks, please do.
> > For the moment, tho, I've attached the source rather than git patch,
> > in case anyone wants to take a look.
> The patch would actually allow me to take a look, (read it in my email
> program, read only the actual changed code, reply to actual quotes of
> the code, and if desired, apply the patch for testing). By contrast,
> complete source code files aren't of much use for any of those
> purposes, (particularly zipped).
> And all of that holds even if the code is preliminary and not intended
> for being applied to cairo's tree---a patch is still greatly preferred.
> > All in all looks pretty good -- checking out some stress tests with more
> > heavy uses of primitives would be interesting.
> Yes, in general I'm always in favor of improving things. Keith wrote
> the original chunky-path storage, and Behdad rewrote it later to
> reduce memory consumption. So another rewrite now to improve it more
> sounds great. Maybe Behdad will have some comment, (or maybe he too
> will wait to see a patch).
I've wanted to reply to the original mail. Doing it now.
> > Open Questions:
> > * Is the code managing reverse traversal of paths necessary. I didn’t
> > (re)implement it in the attached because no one appears to be using it.
> If there are no callers then please remove it. As that's a logically
> separate step, please do that as a separate patch/commit before your
> subsequent work.
> > Regarding the attached code -- it includes a whole bunch of logging code
> > that while useful does make the code less maintainable -- I will
> > probably rip it out before making a real patch.
> And that sounds like something that would work well has a third
> commit, (so that you could submit the complete patch series with three
> commits, but perhaps only the first two would be intended for/applied
> to cairo itself).
> > * What size should cairo_path_fixed_t be set to? comments indicate 512
> > bytes is desirable but I don't think gcc nor visualc achieve that. gcc
> > -- assuming my macro expansions are right -- comes in at a very odd 499
> > bytes.
> I have no suggestion here. Behdad?
If you are talking about the current macro, it leaves 2 * sizeof (void*)
for the libc memory bookkeeping. So, starts with 504 bytes really.
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
More information about the cairo