News for hackers. Stuff that matters.
Re:Temporary fork enables Node.js to optionally use the Chak... by consptheorist on Tuesday May 12, 2015 @04:23PM (#9534596)
Are you suggesting that the remarkable disparity in performance was DOM specific?

Strange because I used a very common method appendChild() and I was under the impression that both browsers had optimized their respective inner workings a long time ago to the point that we should not notice such divergence in performance.

Re:Temporary fork enables Node.js to optionally use the Chak... by dpe82 on Tuesday May 12, 2015 @04:34PM (#9534662)
Yes. DOM manipulation in all major browsers is implemented in C/C++. The JS engine is just a wrapper; any noticeable performance difference in DOM manipulation is almost certainly due to differences in the underlying layout engine and not in the JS engine.
Re:Temporary fork enables Node.js to optionally use the Chak... by gsnedders on Tuesday May 12, 2015 @04:42PM (#9534716)
Well, there's one way in which the JS engine effects it: how efficiently one can call into C++ from JS. Mozilla have done a lot of work to reduce the cost of that in SpiderMonkey.
Re:Temporary fork enables Node.js to optionally use the Chak... by dpe82 on Wednesday May 13, 2015 @08:56PM (#9542917)
Sure, though in the grand scheme of things that penalty is pretty small when compared to the DOM operation itself. Eg. doing an appendChild() on an attached element and causing a reflow.
Re:Temporary fork enables Node.js to optionally use the Chak... by gsnedders on Friday May 15, 2015 @12:08PM (#9551500)
It depends a lot on what you're doing — if you're hitting fast-paths (esp. if you're dealing with out-of-tree nodes) it's entirely possible to end up with the JS/C++ trampoline being a significant part of the bottleneck, for much the same reasons as why Array.prototype.reduce can in several implementations.