Re: Optimizing Pango OpenType engine

[Behdad Esfahbod <behdad cs toronto edu>]

On Sat, 26 Mar 2005, Owen Taylor wrote:

> On Tue, 2005-03-22 at 03:20 -0500, Behdad Esfahbod wrote:
> > [misspelled list name the first time, resending]
> >
> > Hi Owen,
> >
> > As you may have noticed, I'm working around the
> > pango/pango/opentype these days.  I've found a lot of places to
> > improve, and guess I'm going to rewrite the whole thing
> > eventually.
>
> If you are going to be doing extensive work, you might want to
> think about doing it in the context of an independent module
> in freetype CVS rather than in Pango.
>
> http://lists.gnu.org/archive/html/freetype-devel/2004-08/msg00036.html
>
> What I was planning to do was to take the code in Pango CVS,
> import it into the otlayout/, then redo the work that David
> did in otlayout/ to make it work on memory buffers rather than
> FreeType streams.
>
> I never got final sign off from David on this plan, but he's
> back around now, so probably just needs to be repinged.


Ok, so I'm going to get the code in Pango and Qt and roll out a
shared codebase.  For now I would put it in fd.o, unless other
arrangements are done with FreeType people.  Let's follow the
thread in freetype-devel then.

> The opentype code really is pretty tricky ... my experience
> is that few patches to it are right the first time. So, I'd like
> to get multiple pairs of eyes looking at any changes. It doesn't
> have to be me ... if you can get someone else who is familiar
> with the code to review changes, that's OK with me.

Hopefully this problem would be cleared when working nearer to
freetype people.  Indeed the code is tricky, many of the patches
I'm talking about are simply fixs to previous patches.


>  - Stop using FreeType internal headers
>  - Get to a common codebase with Qt

I'm going for it then.


> >   - Reduce number of memory allocations, so faster startup times.
> > Currently loading Arabic tables of Tahoma does 120 allocs and
> > reallocs, 42 of them are allocating only 2 bytes.  For loading
> > the whole supported tables, according to HELLO.utf8, these
> > numbers are 702, 231.
>
> 120 allocs/reallocs isn't very much.... it's not going to show
> up on profiles. Perhaps loading lookups lazilly as needed would
> help reduce the number.

It's somehow lazy already, not?  Or the difference when rendering
HELLO.utf8 comes from allocating buffers for text I suppose.
Anyway, these all vanish when I go for mmapping the font.


> >   - Reduce memory footprint by implementing inheritance by
> > subtyping instead of union-ing all subtypes.
>
> You probably could keep the unions and just allocate the memory
> for the branches you are using, though that can be a little
> tricky. Do you have numbers for how much memory could be
> saved here.

No.  But again, guess this is not necessary i the long term.


> >   - Share code between gsub and gpos subsystems by carefully
> > designing data structures.
>
> There might not be a big advantage to this ... it does feel
> like there is a lot of almost exactly duplicated code, but I'm
> not sure if it can be factored without considerable more
> complexity.

This again would be a completely different problem when mmapping.


> >   - Use call tables were appropriate, to speed up switches.
>
> As far as I know, GCC already does this. Doing it manually
> won't be a win.

As far as the current code is concerned, it's not.  The patch
that I've attached to bug 170414 was done after checking assembly
output from gcc -O2, and it really saves a lot, shows in profiles
too.  Anyway this is not a big deal again, when rewriting.

> >   - Maybe: Map some structures directly on the mapped font file
> > instead of reading them.
>
> This would be pretty much a rewrite... it certainly is a more
> memory efficient way of doing things. I don't have a good sense about
> the relative performance benefits. If you were going to go this
> way, you almost certainly want a separate validation pass, like the
> stuff Werner wrote so that you aren't constantly validating the
> tables.

Sure.  BTW, the current code misses validation badly.  See bug
171170 (and possibly 171575) for example.


> >   - Long term: Cache OpenType structure of fonts in a file?
>
> If you are going to use mmap structures, it's probably best
> to just use the tables in the fonts, as in your previous item
> instead of reinventing some new format.

Sure.

> Regards,
> 					Owen

Thanks,
--behdad
http://behdad.org/