I checked with a coworker on OSX Sierra to see he also experienced the same issue, since he didn't see the memory jump issue. I tried upgrading from Yosemite to Sierra and also saw the memory issue go away. However, there was still a performance issue:

See: https://jsfiddle.net/9ny8m9br/3/

```
measureText('\uFF37') x1000 random font size: 678.69677734375ms
measureText('m') x1000 random font size: 84.05029296875ms
measureText('\uFF37') x1000 fixed font size: 11.560791015625ms
measureText('m') x1000 random font size: 11.537841796875ms
```

eggers.pierola@: there are other memory leak bugs for chrome helper, such as this one:
https://bugs.chromium.org/p/chromium/issues/detail?id=474030

I am not sure whether this one is the same as the above one or not. Could you try something for me:
Open 10 tabs, load the "memory test.html" that I have attached for all the 10 tabs.

The test case is a non-ending animation that in each frame does create a 1*1 ImageData which is only 4 bytes. In theory, after 5~10 mins, each tab should use very small amount of memory. Please let me know how much memory does the chrome helper consume in this case.

Deleted: memory test.html 171 bytes

memory test.html 171 bytes View Download

For the test you asked for, the Chrome Helper memory consumption stayed pretty low. I had just the 10 tabs of that file opened on a fresh start of Chrome, and consumption stayed pretty low for all tabs.

I think that this is probably a different issue that the ticket that you referenced because there is no issue with measureText('m') or measureText('W'), but only with measureText('\uFF37'). Additionally, the issue only really pops up when the font size used to measure the text changes. Even measuring just 'm' at variable font sizes causes an 8x performance degradation, measuring '\uFF37' causes an additional 8x degradation for a total of ~64x slower times. For a comparison, Safari takes ~10ms for each of the calls, and Firefox takes ~100ms.

Deleted: Screen Shot 2017-05-08 at 2.57.32 PM.png 157 KB

	Screen Shot 2017-05-08 at 2.57.32 PM.png 157 KB View Download

OK, I will investigate the performance issue first. I tried on linux, and random font size take >3 times longer than the fixed font size.

Here is what I found so far: https://jsfiddle.net/n7s4bbyz/

If I apply a Math.round() on the font size, it makes the random font size 10 times faster, and then all the four cases in the above page takes about the same time. (Under linux)

@xidac I think that the performance converges simply because you're running 10,000 tests with only 10 different font sizes, so it's basically like running the fixed font size test 10 times.

For example take a look at this modification where I reduced the count to 100 and increased the font size range to be 1-100. It's still an order of magnitude jump between fixed & variable, and an additional order of magnitude between variable 'm' and variable '\uFF37'. However, repeated runs reduces the time taken to be comparable across tests.

https://jsfiddle.net/n7s4bbyz/1/

OK, more investigation on this issue. If you load this page: https://jsfiddle.net/g4jo9osj/, then the elapsed time for all 4 cases are about the same. The only thing is that this time the font is "Arial" instead of "Trebuchet MS Arial".

I have an offline discussion with eae@:
What tends to slow things down the most is font fallback. In the sample case provided in the original report, we tried to measure the width but failed as the font didn't have the required glyph, resulting in falling back to a backup font and then measuring again.

davidqu@chromium.org hasn't logged in in more than 30 days, so this bug showed up in the triage queue.

Update: I took a look at this old bug and can confirm that the original memory leak is gone. But there is still a performance hit when measuring 'uFF37' vs 'W' that gets amplified by two factors in all the test pages mentioned in the bug:

-Using different random font sizes is slower because we cache the results of measureText. That's why fixed size is faster than random, and that's also why rounding the font size makes it faster, since is more likely to hit the cached values.
-When using a font type that doesn't have the glyph we fallback to another font and measure again as mentioned in comment #10. Font fallback is still quite slow.

Considering that, even testing with Arial with various integer sizes from 1 to 1000, measuring \uFF37 still has a considerable (around x10) performance hit compared to measuring W. This is not the case for Firefox or Safari.