[cairo] mallocs in gstate_save

[Behdad Esfahbod]

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.

Cheers,

-- 
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