141–150 of 168 posts
Looks like John-David Dalton has some work cut out for him!
lodash is as fast as fast: see the JSPerf results posted elsewhere. John manages lodash well. He has managed it well for quite a while. Why switch to another library with no track record for little or no gain?
Earlier quoted context omitted.
I have a feeling that certain things (e.g., reduce) will suddenly become much more performant with tail call optimization coming in ES6.
Would tail call optimization help in this case? AFAIK JS's iteration methods aren't recursive.
It simply refers to 'unrolling' that function call, so a new function doesn't need to be added to the stack.
JS's iteration methods aren't currently recursive, at least in V8[0]. But that's probably due to lack of TCO!
Earlier quoted context omitted.
A few months ago, I tried some image processing with JS and the canvas object (big Arrays). They have a structure like image[pixel].color What I found was, always traversing the object structure was much slower than putting every pixel color as an argument in a function, that gets called every iteration. So I had the impression, reasonable simple function, like a greyscale filter, get inlined by engines like V8.
You probably would have been better off with typed arrays and fragment shaders, if you were going for performance.
But perf problems are more numerous still for these functional methods, because compilers in general have trouble inlining closures, especially for very polymorphic callsites like calls to the callback passed in via .map or .forEach. For an account of what's going on in SpiderMonkey, I wrote an explanation about a year ago [2]. Unfortunately, the problems still persist today.
[1] https://news.ycombinator.com/item?id=7938101 [2] http://rfrn.org/~shu/2013/03/20/two-reasons-functional-style...
Reminds me of this comment by Petka Antonov on native V8 Promises being way slower than Bluebird[1]: >I'd expect native browser methods to be an order of magnitude faster. Built-ins need to adhere to ridiculous semantic complexity which only gets worse as more features get added into the language. The spec is ruthless in that it doesn't leave any case as "undefined behavior" - what happens when you use splice on an a…
So not just JS - it seems language built-ins are often slowed down by bureaucratic spec compliance, and hand-rolling code can help you get a speedup.
Today i was refactoring some js code that rendered a graph to svg. It was taking several seconds in some cases, and the developer had done a bunch of micro-optimizations, inlining functions, building caches to avoid nested loops, and so on. I ran a profile. The code ran for 2.5 seconds, 4 ms of which in the micro-optimized js code, the rest updating the dom, five times all over again. Needless to say that i threw out…
Premature optimization is the root of all evil -- Knuth V8 has excellent profiling tools (exposed in chrome and in nodejs) which should be used first before considering fallbacks. Before seeking a third party library, be sure to check if the function is called many times or is taking a long time. For example, I found that throwing map out and using a straight array (avoiding the function calls entirely) can be up to…
I think it's a bit unfair to label using a known fast library over a known slow library as "premature optimization". I would much rather start a project or feature with the coding standard of, "use the fast ones", rather than have to go back through all the code, profile it, and replace only the ones hurting performance.
This is not the case with Fast.js as it breaks away from the language specifications. I'd much rather build, profile, and then optimize the few areas that actually require better performance than potentially introduce bugs by replacing the built-in methods.
Today i was refactoring some js code that rendered a graph to svg. It was taking several seconds in some cases, and the developer had done a bunch of micro-optimizations, inlining functions, building caches to avoid nested loops, and so on. I ran a profile. The code ran for 2.5 seconds, 4 ms of which in the micro-optimized js code, the rest updating the dom, five times all over again. Needless to say that i threw out…
An ignorant question -- why do people prefer to render graphics to SVG/DOM, when that's such a noticeable performance bottleneck?
For example, with IE on Win8, your DOM UI is actually composed of DirectComposition layers, and touch manipulations (pan, zoom, swipe, etc) are performed entirely on a separate thread from your UI+JS using DirectManipulation and a kernel feature called delegate input threads, controlling animations of the composition layers on yet another (composition) thread. You'll have a heck of a time matching that with canvas and mouse/touch/pointer events on your lone JS UI thread and the dozens of responsibilities it's signed up for.
Again, it depends a great deal on what you're doing. And it's a trade-off for sure... DOM is expensive, and if you're doing something too complicated then having panning and hit-testing on another thread doesn't help if the user ends up seeing large unpainted regions for a while, or if you make your startup time painful by trying to build a complex scene upfront. But you asked, so I answered :-)
There are also other important considerations:
1) It's easier (at least until we get some awesome UI frameworks on top of canvas, if that works out well).
2) It's compatible with older browser versions.
3) DOM layouts and controls support various accessibility features, input modalities, etc.
4) There's a huge library of tools/utilities/reusable components all designed specifically for it.
(I used IE/Win8 as an example because I'm familiar with how that works in great detail. Last I knew no other platforms were that aggressively optimized in those respects but presumably some are part way there)
Earlier quoted context omitted.
I actually didn't get any speedup with that one -- looks like V8 can optimize that already. But you're right, that's an important one on some browsers. You can squeeze out another factor of 2 with typed arrays: var input_typed = new Uint32Array(input) exports['numeric typed array'] = function() { var acc = 0; for (var j=0; j And probably more still if you can figure out the asm.js incantation that makes everything st…
The optimisation mentioned by the grandparent is specific to looping overso-called "live" collections of the DOM. NodeList [0] is sometimes a live collection, and is the return type of querySelectorAll, so it's likely you've dealt with this type of collection. The reason it incurs an overhead is because the DOM is traversed every single time the property is read, to ensure nothing has changed. You can see why caching…
I suspect a lot of the optimization opportunity in browsers today is less about JS or DOM in isolation but more about ways they could work together to improve situations like this one.
(Note: I understand this one is solvable by a proficient/attentive developer, but not all developers are like that, and not all such DOM/JS transition problems are as easily solvable from your JS code)