esprehn

// Sample virtual vs switch, compiled with
// clang++ -std=c++11 -O3 benchmark.cpp
//
// Tested on a MBP:
//
// Computed 33332
// virtual loop(474 ticks, 0.000474 seconds)
// Computed 33332
// switch loop(173 ticks, 0.000173 seconds)

esprehn

// Sample virtual vs switch.
// clang++ -std=c++11 -O3 benchmark2.cpp && ./a.out

#include <iostream>
#include <ctime>
#include <vector>

class Base {
public:
  virtual int test(int value) = 0;

esprehn

// Sample virtual vs switch.
// clang++ -std=c++11 -O3 benchmark3.cpp && ./a.out
//
// Tested on a MBP:
//
// switch loop(10712 ticks, 0.010712 seconds)
// shuffled switch loop(10587 ticks, 0.010587 seconds)
// virtual loop(10583 ticks, 0.010583 seconds)
// shuffled virtual loop(14292 ticks, 0.014292 seconds)

esprehn

// Sample virtual vs switch.
//
// Tested on a MBP:
//
// switch loop(965945 ticks, 0.965945 seconds)
// shuffled switch loop(915787 ticks, 0.915787 seconds)
// switch loop ptrs(993597 ticks, 0.993597 seconds)
// shuffled switch loop ptrs(1957770 ticks, 1.95777 seconds)
// virtual loop(931314 ticks, 0.931314 seconds)
// shuffled virtual loop(1905250 ticks, 1.90525 seconds)

esprehn

/*
  This is a rough approximation of what the algorithm woud do. In an
  implementation you might make the JS Wrapper point to a different
  C++ Element for the duration of the constructor, then make it
  point back at the original C++ element, and move data between them.
  
  This means that the C++ side remains consistent, if you querySelector
  from the document you can still find your element where the constructor
  is running, but if you look at the parentNode/firstChild or attributes
  properties of the element they all appear empty. This means in the

esprehn

/*
  This is a rough approximation of what the algorithm woud do. In an
  implementation you might make the JS Wrapper point to a different
  C++ Element for the duration of the constructor, then make it
  point back at the original C++ element, and move data between them.
  
  This means that the C++ side remains consistent, if you querySelector
  from the document you can still find your element where the constructor
  is running, but if you look at the parentNode/firstChild or attributes
  properties of the element they all appear empty. This means in the

esprehn

var createNewRegistrationContext = (function() {
  // This is slow and means using more memory keeping the iframe window alive,
  // but there's no other way to get a fresh registration context. :(
  var iframe = document.createElement("iframe");
  iframe.style.display = "none";
  document.documentElement.appendChild(iframe);
  var lastDocument = iframe.contentDocument;
  return function() {
    // This keeps nesting template documents to create new registration
    // contexts.

esprehn

Clockwise from podium:

Alan Stearns (Adobe)
Cameron McCormack, heycam (Mozilla)
Xidorn Quan (Mozilla)
Jet Villegas (Mozilla)
Rossen (Microsoft)
Bert Bos
Joone Hur
David Baron (Mozilla)

esprehn

dictionary CSSStyleSheetInit {
  // TODO: Should also take a MediaList, but those have no constructor. When
  // it does take those, it should make a copy so mutations to the list don't
  // impact the sheet. This is for v2 of the API.
  DOMString media = "";
  DOMString title = "";
  boolean alternate = false;
  boolean disabled = false;
};

esprehn

DocumentStyleSheetCollection::updateActiveStyleSheets  mode=0 type=0 full=1
#0 0x7fc54872a153 base::debug::StackTrace::StackTrace()
#1 0x7fc53e16eb10 blink::DocumentStyleSheetCollection::updateActiveStyleSheets()
#2 0x7fc53e1c4b09 blink::StyleEngine::updateActiveStyleSheets()
#3 0x7fc53e080d8d blink::Page::settingsChanged()
#4 0x7fc5476af266 blink::WebSettingsImpl::setStandardFontFamily()
#5 0x7fc5464f3cd7 content::RenderView::ApplyWebPreferences()
#6 0x7fc5464f2458 content::RenderViewImpl::Initialize()
#7 0x7fc5464f4917 content::RenderViewImpl::Create()