fillText has a performance cliff when printing strings of length 16 and greater
Reported by
rick.l...@tradingtechnologies.com,
Dec 7 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 Steps to reproduce the problem: 1. call fillText with strings of increasing length and note the performance cliff reached for length >= 16 2. 3. What is the expected behavior? What went wrong? Performance of fillText is faster than drawImage (where drawImage is called n times, where n is the length of the string), except for strings of length 16 or greater, in which case fillText hits a performance cliff which can be seen in the attached code snippet. Did this work before? N/A Chrome version: 54.0.2840.98 Channel: n/a OS Version: OS X 10.10.2 Flash Version: Shockwave Flash 23.0 r0
,
Dec 7 2016
For convenience, here is the test on jsFiddle: https://jsfiddle.net/96LL1Lyw/ Benchmark output is in the dev console.
,
Dec 9 2016
This is by design, the shaping results for strings 15 characters and below are cached while strings longer than that are not. The rational being that shorter strings require less memory to cache and are much more likely to appear multiple times in a document. The tradeoff between memory usage and performance is always tricky. We might want to adjust the caching logic or allow for a small number of longer strings if this turns out to be a problem for real-world content. |
||
►
Sign in to add a comment |
||
Comment 1 by junov@chromium.org
, Dec 7 2016Status: Available (was: Unconfirmed)