Hacker News Reader

Comment by maxbrunsfeld | Hacker News Reader

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 between JS and C++?

View on HN

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.

> 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

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.

Reply on news.ycombinator.com