On Thu, Mar 1, 2012 at 7:18 PM, Ojan Vafai 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 time in the ne
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 a
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,
On Thu, Mar 1, 2012 at 4:50 PM, Ojan Vafai 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,
> ContainerNode::removeChild n
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
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
6 matches
Mail list logo
