Re: [ft-devel] Major performance regression for FT_LOAD_TARGET_LIGHT on mingw-w64

[Werner LEMBERG]

> ImageMagick has a big performance bottleneck on mingw-w64 (windows)
> caused by the use of FT_LOAD_TARGET_LIGHT. A minimal example:
> https://gist.github.com/jeroen/ac238d8254197991da779ce44ee0b702
> 
> Calling FT_Load_Glyph() with FT_LOAD_TARGET_LIGHT leads to a 60x
> performance regression. On my machine, the total time to run the
> program above goes from 0.1s to 6.12 sec. I am using freetype 2.8
> with mingw-w64 gcc 7.1.0 from msys2, but I have also reproduced this
> problem with gcc 4.9.3.  This problem only seems to appear on
> mingw-w64 windows, both in 32bit and 64bit.

Please do `git bisect' to find the problematic commit – if there is
one.  Calling something a `regression' without telling the base to
compare with doesn't help.

You might also run a profiler to find out the hot spots.

> Interestingly, when FT_LOAD_TARGET_LIGHT is enabled, the cpu time
> for each call to FT_Load_Glyph() is almost exactly 0.024s.  This
> suggests there is some sort of timeout or race condition.

I don't think so.  Maybe you are now properly linking with HarfBuzz,
which scans a font's GSUB and GPOS tables to find out which glyphs are
to be assigned to which script by the autohinter?

> In the example above, if we move FT_New_Face() outside of the loop,
> only the first call to FT_Load_Glyph() is slow.

This seems to support my assumption.  Most of FreeType's font
initialization is lazy, to be run only where necessary (usually
triggered by calls to `FT_Load_Glyph').

> All subsequent calls are immediate.  However in the context of
> e.g. ImageMagick recycling the FT_Face is not an option.

Well, the code in your snippet is contrary to the normal usage pattern
of FreeType...

> I tried rebuilding freetype2 with various configurations but I was
> unable to solve the problem.

I don't see a problem in FreeType.  Honestly spoken, the problem is
the code in ImageMagick.  To be more precise, the code is very, very
old-fashioned; for example, it can't handle kerning from the GPOS
table.  Similarly, the code is not suitable to handle anything else
but the most primitive scripts like Latin or Cyrillic.  Anything more
complicated like Arabic or Indic fails.

Consequently, I suggest that you replace this simplistic code with
calls to a modern layout library like Pango or ICU.


    Werner