We can talk about that tomorrow.<br><br><div class="gmail_quote">2010/4/9 Ojan Vafai <span dir="ltr">&lt;<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>Chromium has a bunch of perf bots that we run continuously. Most of these are just page cyclers that loop through pages. They&#39;re grouped by different types. You can see some graphs here: <a href="http://build.chromium.org/buildbot/perf/dashboard/overview.html" target="_blank">http://build.chromium.org/buildbot/perf/dashboard/overview.html</a>. The more stable bots will also turn red on perf/memory regressions.</div>




<div><br></div><div>This is really useful data that it would be awesome to have at a more granular level than each time chromium pulls in a new webkit revision. Also, it would be great to have this upstream so that it doesn&#39;t depend on chromium engineers to notice and help run the tests.</div>




<div><br></div><div>This came up recently due to a perf/memory regression from <a href="http://trac.webkit.org/changeset/57215" target="_blank">http://trac.webkit.org/changeset/57215</a> on Mac loading international pages (see <a href="http://build.chromium.org/buildbot/perf/mac-release-10.5/intl2/report.html?history=150&amp;rev=-1" target="_blank">http://build.chromium.org/buildbot/perf/mac-release-10.5/intl2/report.html?history=150&amp;rev=-1</a>). With that data we were able to find the root problem and have a path forward for fixing it <a href="https://bugs.webkit.org/show_bug.cgi?id=37292" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=37292</a>.</div>




<div><br></div><div>What would it take to support these (the ones that test web page perf) in upstream WebKit?</div><div><br></div><div>Some initial thoughts:</div><div>1. Machines for the new bots.</div><div>2. Make the page cyclers work with Safari (DRT?). I imagine this is not too hard.</div>




<div>3. Make the data available. Currently, these are on Chrome&#39;s internal svn repo. I think this is due to fear of copyright infringement if we were to publicly distribute them (i.e. a copy of someone else&#39;s copyrighted website). I don&#39;t know the details here and IANAL, so I don&#39;t know how hard this is to workaround. Seems like we ought to be able to figure something out though.</div>




<div><br></div><div>Any interest? Anyone willing to do the grunt work?</div><div><br></div><div>Maybe this is a good topic for the webkit conference.</div><div><br></div><div>Ojan</div><div><br></div><div><br></div><div>



Abberviated #webkit discussion:</div>
<div><div>[11:29am] smfr: why doesn&#39;t webkit have data like that?</div><div>[11:30am] smfr: ojan: it sucks that such data are not available via <a href="http://webkit.org" target="_blank">webkit.org</a></div><div>[11:30am] ojan: smfr: i agree</div>




<div>[11:30am] smfr: we should be measuring page load and memory use for every build</div><div>[11:30am] ojan: smfr: no argument from me</div><div>[11:30am] dglazkov: smfr, ojan: we totally should.</div><div>[11:31am] Catfish_Man: mmm delicious delicious metrics</div>




<div>[11:31am] smfr: any volunteers?</div><div>[11:31am] dglazkov: I volunteer ojan</div><div>[11:32am] ojan: dglazkov: i unvolunteer myself!</div><div>[11:32am] dglazkov: then I volunteer smfr</div><div>[11:32am] ojan: but i fully support someone else moving these tests to webkit</div>




<div>[11:32am] smfr: we need a good server-side hacker</div><div>[11:32am] smfr: that&#39;s not me</div><div>[11:33am] dglazkov: so would it be a matter of hooking up DRT to run various tests and putting up a bot?</div><div>




[11:33am] enrica: great project for an intern </div></div>
</blockquote></div><br>