On Tue, Oct 6, 2015 at 11:03 PM, Werner LEMBERG <[email protected]> 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 >
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
