21451 2008-10-07 15:29:12 -0700 tune cMaxInactiveFontData when cleaning old FontData 2011-05-05 09:03:43 -0700 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX P2 Normal --- 1 mbelshe dglazkov ddkilzer mitz mjs playmobil slewis oldest_to_newest 94459 0 mbelshe 2008-10-07 15:29:12 -0700 When Chromium picked up the latest WebKit; we discovered that our international page cycler test took a ~20% performance hit. This was due to the FontData cleanup. The test is a bit brutal, as it intentionally uses more fonts than users are likely to use. It turns out that tuning cMaxInactiveFontData (FontCache.cpp) from a constant 120 to a constant 256 works around the problem with this test. I'm hoping that this value is currently somewhat arbitrary, so that nobody objects to this change. However, I could submit a patch to allow platform-specific tuning of this value if that is preferred. 94461 1 mitz 2008-10-07 15:56:23 -0700 How much more memory does that amount to? What about other scarce resources used by the cache (GDI handles perhaps)? 94484 2 hyatt 2008-10-07 17:52:08 -0700 I'm fine with raising the constant if Dan is. 97874 3 mjs 2008-11-06 13:48:35 -0800 I think an international test of this sort would almost certainly use more fonts than any normal user would, since most people do not browse to pages using many different scripts. I do not think it would be a good tradeoff to use more memory for solely for the benefit of such a benchmark, if we do not think it would help any real browsing scenario. However, it would help to have data on the increase in memory use from changing this constant. 97875 4 mjs 2008-11-06 13:49:42 -0800 Another useful piece of data would be to determine how many different fonts are loaded in the course of typical browsing for various users. 119631 5 dglazkov 2009-05-01 14:10:05 -0700 I think we'll roll our fork out and see what difference it makes. 398755 6 dglazkov 2011-05-05 09:03:43 -0700 Obsoleting old bugs.