[Webkit-unassigned] [Bug 37292] http://trac.webkit.org/changeset/57215 caused perf/memory regressions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 21 14:54:41 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=37292





--- Comment #14 from Ojan Vafai <ojan at chromium.org>  2010-04-21 14:54:40 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > Yeah I really should not have put r+ on the original bug.  I'll take some of
> > > the blame for that.  It was obvious that the bug was going to regress the
> > > performance of the complex text code path, and I shouldn't have let that slide.
> > 
> > According to Ojan’s testing, that is not correct. The complex path has not
> > become measurably slower.
> > 
> Unless Ojan tests provide a different picture of the problem, here is where I
> think we stand:
> 1. we no performance impact for the simple text path
> 2. we have very small impact on the complex text path (but I don't have the
> exact numbers)
> 3. where things have gotten worse is where we started using the complex path
> for cases where we used to use the simple one.

This is my understanding as well, but I don't know this code or this patch well
enough to say. One thing to note, both my testcase and the Chromium page load
tests do *not* restart the browser between loads of pages. So any perf hit from
loading extra font data that is then cached would not appear on either test
since each page is loaded many times.

What does appear very clearly however is the memory regression. Is there
anything we can do here? Can we store the bounding box only for a certain range
of glyphs instead of all complex text?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list