I don't know if it is cached or not, but taking 15ms for rendering 300 characters, most of them spaces, size 12 (102 dpi) on a Intel 2500 seems to much.
Here is the profiling: <https://lh3.googleusercontent.com/-nJCSqZMDH4A/WBNqE7Q9yYI/AAAAAAAAAnE/oYN0CnQqrSIO_mD6mUArRqVbHK3xJGMOwCLcB/s1600/Captura%2Bde%2Bpantalla%2Bde%2B2016-10-28%2B17-03-20.png> I call measure string around 3 times per line because the text is colored and I need to know what pixels should I color. El miércoles, 26 de octubre de 2016, 7:20:30 (UTC+2), Nigel Tao escribió: > > On Tue, Oct 25, 2016 at 9:40 PM, David M. <manxi...@gmail.com > <javascript:>> wrote: > > Is the Go freetype library optimized? Should I expect a similar > performance > > from the original C version? Why freetype don't use an internal cache to > > store most frequent characters? > > Go freetype has had some performance work, but not a lot. > > I don't have any hard data, but I'd expect it to be e.g. within 2x > worse of the original C version, but not as bad as than 10x worse. > > Go freetype should use an internal cache for glyph image masks. Do you > have evidence that this cache is not being used? > > Can you link to your code? > > The https://blog.golang.org/profiling-go-programs blog post is a > little old, but it should still give some leads on how to profile your > Go code at the function level, not just a coarse "70 fps" number. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
