<div dir="ltr">On Tue, Feb 18, 2014 at 7:44 AM, Adam Barth <span dir="ltr">&lt;<a href="mailto:abarth@webkit.org" target="_blank">abarth@webkit.org</a>&gt;</span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa <span dir="ltr">&lt;<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>&gt;</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&#39;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&#39;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&#39;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&#39;t quantify that until we removed the feature entirely last year.  That&#39;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><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&#39;ve done in Blink.  After removing the N^2 algorithm, shadow DOM related code falls off the profile completely.</div>


</div></div></div></blockquote><div><br></div><div>Makes sense.  I think one big problem with the old implementation was that it started off with a completely different API and feature set and the code had to &quot;evolve&quot; as the spec developed further over years and accumulated design kinks.  I&#39;m sure we can avoid introducing O(n^2) algorithms if we started from scratch looking at the latest design.</div>


<div><br></div><div>- R. Niwa</div><div><br></div></div></div></div>