freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] gray_render_scanline: very hot when fuzzing


From: Kostya Serebryany
Subject: Re: [ft-devel] gray_render_scanline: very hot when fuzzing
Date: Tue, 6 Oct 2015 23:35:21 -0700



On Tue, Oct 6, 2015 at 11:03 PM, Werner LEMBERG <address@hidden> wrote:

> BTW, w/o rendering the profile looks like this:
> 25.92%  tt_cmap4_next
> 15.37%  tt_cmap4_char_next
> 7.32%  FT_Get_Next_Char
> 5.11% memset
>
> Does this look normal?

I think yes.  The cmap4 map support is extremely flexible, being able
to handle almost completely broken tables – this is for backwards
compatibility, since there are zillions of old fonts in the wild that
do not conform to the standard.  Of course, this flexibility has quite
a high price.  For example, FreeType has code for both a binary search
(tt_cmap4_char_map_binary, for correct tables) and a linear search
(tt_cmap4_char_map_linear, for broken ones), the latter being slow by
nature.

Fonts modified by the fuzzer will trigger the linear code much more
often than the binary code.  In other words, the fuzzer distorts the
real-world use case that assumes valid fonts, thus producing
exaggerated profiler percentages.


Yep, that's what fuzzers do!

Thanks for the explanation about the internals. 
At the current point and with the current target function fuzzing runs at 600 exec/s per CPU, 
which is not bad. 
Unless there is a simple change that
can give 2x or more speed up -- we can just wait a bit longer.  

--kcc 
 
 
Note also that FT_Get_Next_Char itself is an expensive function, also
by nature – TrueType cmap tables are not set up well for doing this
operation, and we access them on demand, no longer storing them in
separate structures to reduce memory usage.  Reason is that for normal
glyph display you don't have to walk over all characters; this is
rather limited to special applications like FontConfig, which has to
analyze the whole font before adding it to its database to find the
covered Unicode blocks.

On the other hand I can imagine that an analysis of a more detailed
profile of the binary and linear cmap code identifies some hot spots,
which could probably be eliminated.


    Werner


reply via email to

[Prev in Thread] Current Thread [Next in Thread]