Closed Bug 559311 Opened 10 years ago Closed 10 years ago

[HTML5] nsContentUtils::CreateContextualFragment doesn't cache HTML5 parser properly

Categories

(Core :: HTML: Parser, defect)

x86
All
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Based on Shark profiles nsContentSink::Init (or calls under it) takes
6.3% of setting .innerHTML.
Seems like most of the time is spent in getting some prefs.

This isn't really HTML5 parser bug, but shows up when using html5 parser and
testing innerHTML.

A bit dummy testcase is here https://bug404385.bugzilla.mozilla.org/attachment.cgi?id=289857
For some reason nsHtml5Module::NewHtml5Parser() seems to be called a lot.
Parser should be cached, but somehow it is not.

Patch coming.
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Modifying summary, since the problem is really about not-caching the parser.
Summary: [HTML5] nsContentSink::Init call is slow → [HTML5] nsContentUtils::CreateContextualFragment doesn't cache HTML5 parser properly
Attachment #438975 - Flags: review?(hsivonen) → review+
http://hg.mozilla.org/mozilla-central/rev/d9d7de04f75d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I think this patch caused bug 559683
I'll backout this for now until the reason for bug 559683 is found.
It sounds like an HTML5 parser issue.
http://hg.mozilla.org/mozilla-central/rev/ec1616d0be38
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Jim, if you could try now whether you can still reproduce bug 559683.
(I've seen bug 559683 too. Very annoying bug.)
With the backout all is good again.  Ran the browser overnight with my normal set of tabs, and all is good this morning, no leaks/creep on memory use.
I expect this patch to fix the memory problem.
Attachment #440206 - Flags: review?(Olli.Pettay)
Comment on attachment 440206 [details] [diff] [review]
Drop held elements at the end of ParseFragment

I've been running a build with both these patches for 16h now and
tbpl hasn't cause any major memory increase.
So perhaps we could land both patches.
Attachment #440206 - Flags: review?(Olli.Pettay) → review+
http://hg.mozilla.org/mozilla-central/rev/08bd8eb86673
http://hg.mozilla.org/mozilla-central/rev/d16525937c8b

Jim , if you still see the fast increase in memory usage, please reopen this 
(or bug 559683).
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Marking this Verified Fixed,  been running solid here past two days with no memory creep. 

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre ID:20100423040128
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.