innerText causes memory leaks
Reported by
federico...@gmail.com,
Jan 4 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Open the test case (or http://s.codepen.io/FezVrasta/debug/pRomWL) 2. Open the dev tools and go to timeline 3. Refresh the page to let the timeline capture start 4. Watch the result of the capture What is the expected behavior? A low number of nodes is present in the capture timeline What went wrong? An impressive number of nodes is detected Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0
,
Jan 6 2017
,
Jan 10 2017
The innerText spec requires us to create a new node; reusing a node isn't really a feasible or good idea. FWIW in Chrome 55.0.2883.87 (Official Build) (64-bit) I never got that many (thousands) on nodes in my trace. Having a lot of nodes in memory isn't necessarily bad. It may be better to delay collecting them to get through that loop so the system can be responsive again sooner. (Not saying the heuristic is necessarily tuned to do that; just that transient number of nodes isn't necessarily a bug.) Does the node count drop back down after a bit? What's the specific problem with a large number of nodes in this case?
,
Jan 10 2017
as far I can see, the number of nodes never drop..it reaches a number and never grows further. in my case the problem was that all these nodes in memory caused lags.
,
Jan 11 2017
I'm sorry but I can't seem to reproduce this in Chrome on Mac 57.0.2978.0, I see dozens of live nodes at most. If you can quantify the lags you were seeing and help us reproduce the problem that would be wonderful. |
||||
►
Sign in to add a comment |
||||
Comment 1 by federico...@gmail.com
, Jan 4 2017