<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 18, 2014, at 7:44 AM, Adam Barth <<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">Hi Ryosuke,</div><div><br></div></div><div class="gmail_quote">On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Now that we've removed all of the existing shadow DOM implementations from trunk in <a href="http://trac.webkit.org/changeset/164131" target="_blank">http://trac.webkit.org/changeset/164131</a>, I'm intending to work on new web components implementations in a branch based on the feedback Apple has given on public-webapps and www-style in near future, probably starting with custom elements.<br>
</div>
<div><br></div><div>I'd like to implement them in a branch to not inadvertently introduce performance regressions. The old implementation on trunk resulted in 5% overall slowdown in the page load time but we didn't quantify that until we removed the feature entirely last year. That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions. Development in a branch allows a faithful performance comparison between the two.</div>
</div></blockquote><div><br></div><div>The approach we were successful with in Blink was to restructure how we construct the render tree. At the time Blink branched from WebKit, the algorithm we both used to construct the render tree was N^2. The inner loop of the N^2 algorithm contained more complex DOM traversals due to shadow DOM. When you profile the code, it looks like shadow DOM is expensive, but the bigger win is just to remove the N^2 algorithm, which we've done in Blink. After removing the N^2 algorithm, shadow DOM related code falls off the profile completely.</div>
<div><br></div><div>I hope you view this message as constructive feedback. My hope is that you'll be successful implementing shadow DOM, and I wanted to share what we've learned in case that's useful to you.</div>
</div></div></div></blockquote><br></div><div>Thanks, Adam. We hope that we will be successful implementing shadow DOM as well.</div><div><br></div><div>Do you have any more specific pointers that Ryosuke et al could look at for the O(N^2) algorithm? Like a commit range or a function to look at?</div><br><div>Cheers,</div><div>Maciej</div></body></html>