Bug 47316

Created attachment 70020 [details] experiment

Initial testing shows this as a loss: == before == Running 20 times Ignoring warm-up run (3278) 2729 2737 2722 2710 2745 2734 2725 2731 2749 2737 2735 2770 2754 2743 2747 2773 2762 2751 2771 2780 avg 2745.25 stdev 18.2944663764757 == after == Running 20 times Ignoring warm-up run (3087) 2805 2810 2807 2801 2817 2830 2826 2812 2821 2846 2838 2828 2829 2862 2856 2845 2844 2848 2875 2864 avg 2833.2 stdev 20.894018282752604 Thoughts?

I suspect our lazyAttach logic needs to be made more efficient before we use it.

I suspect our lazyAttach logic needs to be made more efficient before we use it.

I don't see a perf loss with this patch anymore, maybe even a slight win (?). On my quad-core iMac, I see == before == Running 20 times Ignoring warm-up run (802) 799 822 823 804 802 801 802 808 805 804 804 805 808 806 812 805 809 809 811 809 avg 807.4 median 805.5 stdev 6.011655346075654 min 799 max 823 == after == Running 20 times Ignoring warm-up run (811) 815 817 801 800 794 801 797 796 799 796 798 801 798 802 803 801 802 811 803 803 avg 801.9 median 801 stdev 5.864298764558298 min 794 max 817

This is more Eric's department than mine.

lazyAttach will show as profitable only on some cases, right? It's useful when there are lots of attach-inducing changes in a given bit of time, and lazyAttach helps batching up these changes. So the maximum win will be in large chunk of script, which sparsely makes changes to DOM -- the lazyAttach saves you multiple re-traversals of the tree. In the case of parser, you already do the batching, since _all_ of the parser DOM modifications are attachment-related. So I don't think the parser will ever see a significant win in lazyAttach. However, we should still make this change in an effort to get rid of non-lazy attach(). http://www.youtube.com/watch?v=kq4SqgxIKM0

The code here has changed too much to consider this.