[cairo] mallocs in gstate_save
behdad at behdad.org
Thu Nov 15 18:25:48 PST 2007
On Thu, 2007-11-15 at 18:50 -0500, Vladimir Vukicevic wrote:
> On Nov 14, 2007, at 4:09 AM, Chris Wilson wrote:
> > Baz (brian.ewins at gmail.com) said:
> >> So, my question is - would it be sensible in this case to just hang
> >> on
> >> to the previous alloc (just reducing allocs rather than addressing
> >> the
> >> fragmentation issue). Something like the code below;
> >> _cairo_gstate_destroy would become tail-recursive to free this up
> >> later.
> > I was profiling swfdec last week and saw that it used save()/restore()
> > quite frequently and so I added a gstate freelist to cairo_t. My
> > goal at
> > that time was to build benchmarks for XShm, so I didn't pursue that
> > digression... (Since then I've been looking at pre-allocating chunks
> > for
> > the freelists.)
> Hey, this looks great.. I was going to suggest implementing a freelist
> when I heard about the allocations in use. Patches look fine to me,
> though Carl or Behdad should have a look as well.
> - Vlad
I somehow managed to misplace Chris's original mail. Well, I'm not very
enthusiastic about the patch. From what I gather it's allocating a
chunks of gstates, 2048 bytes in size; good, but then attaches it to a
cairo_t which is a very short-lived object. Sure it's better than
current situation, but i think we can do better.
So, what can we do? Not sure. A simpler way to implement the same
scheme is to just enlarge the gstate embedded in cairo_t to contain more
than one gstate. That's what I've done in other places in cairo.
"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