4 ms·

I'm curious about the source of the slowness of the IDL operations. Is it specific to the DOM, or is he referring to overhead that exists for any bindings betwe

• bzbarsky 10y ago
  IDL operations are not particularly slow. Last I measured, a call from JS into C++ is between 10 and 40 CPU instructions of fixed overhead depending on the exact thing being called (method vs getter vs setter; they have slightly different costs) and the browser involved. At least once you get into the top JIT tier; baseline jit and interpreter can involve more overhead, obviously. There's additional cost for dealing with the call arguments, too; this varies widely by type of argument (e.g. an options object is clearly more expensive to deal with than a boolean, or even than a list of arguments containing the same information as the options object) and somewhat less widely by browsers.
  • pcwalton 10y ago
    > IDL operations are not particularly slow. Last I measured, a call from JS into C++ is between 10 and 40 CPU instructions of fixed overhead To put that in perspective, that's the same number of instructions as objc_msgSend, which every Objective-C method call in native iOS or Mac apps goes through [1]. "The DOM is slow compared to native" is a common meme, but it's not that simple. [1]: http://sealiesoftware.com/msg/x86-mavericks.html http://sealiesoftware.com/msg/x86-mavericks.html
• gsnedders 10y ago
  Any bindings across the boundary tend to be far more expensive than a JS -> JS or C++ -> C++ call. This is why initial implementations of Array.prototype.map, for example, were slower than just doing it all in JS.