We have a lot of code (e.g. in ContainerNode.cpp or any of the editing
code) that needs to RefPtr nodes to make sure they're not destroyed due to
synchronous events like blur, mutation events, etc. For example,
ContainerNode::removeChild needs to RefPtr the parent to make it's not
destroyed during
Do we understand what's causing the performance regression? For
example, there are other implementation approaches where we try to
transfer the last ref rather than churning it or where we could use a
free list rather than a vector. I just wonder if there's a way to get
the benefits with a lower
On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai o...@chromium.org wrote:
We have a lot of code (e.g. in ContainerNode.cpp or any of the editing
code) that needs to RefPtr nodes to make sure they're not destroyed due to
synchronous events like blur, mutation events, etc. For example,
I agree with Adam's remarks. The safety benefit seems great, but we should
investigate ways to get it at less performance cost (ideally no measurable
cost).
I'm also curious what impact this change has on less micro- but still
DOM-oriented benchmarks, such as Dromaeo's DOM tests, Peacekeeper,
I think my earlier testing was faulty. Now when I test case 2, I get
something comparable with and without the patch. If there is a regression,
it's below the noise. Running it through a profiler shows a negligible
amount of time in the new code.
I had tried running it through Dromaeo first, but
On Thu, Mar 1, 2012 at 7:18 PM, Ojan Vafai o...@chromium.org wrote:
I think my earlier testing was faulty. Now when I test case 2, I get
something comparable with and without the patch. If there is a regression,
it's below the noise. Running it through a profiler shows a negligible
amount of
6 matches
Mail list logo
