<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>On 2/18/14, 13:54 , &quot;Maciej Stachowiak&quot; &lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt; wrote:</div>
<span id="OLK_SRC_BODY_SECTION">
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div 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 &lt;<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>&gt; 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">
&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'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. &nbsp;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. &nbsp;That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions. &nbsp;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. &nbsp;At the time Blink branched from WebKit, the algorithm we both used to construct the render tree was N^2. &nbsp;The inner loop of the N^2 algorithm contained
 more complex DOM traversals due to shadow DOM. &nbsp;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. &nbsp;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. &nbsp;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>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>I think it may be:&nbsp;https://codereview.chromium.org/24350009</div>
</body>
</html>