131–140 of 168 posts
Earlier quoted context omitted.
An ignorant question -- why do people prefer to render graphics to SVG/DOM, when that's such a noticeable performance bottleneck?
I can't speak for others, but if you write browser apps/websites for a generic audience you basically have no choice. The reason consist of two letters: IE
Earlier quoted context omitted.
Note that 'in' for (key in object) is for getting keys, in Firefox, meanwhile 'of' for (value of iterator) is for getting values out of an Iterator.
Most of the array methods are explicitly defined in terms of indexing rather that iterators, so for(of) is incorrect. On the other hand indexing is still faster than iteration in the major implementations.
How do you mean when you state that for(of) is incorrect?
Perhaps this 'example' clears something up?
« for (value in {a:1,b:2,c:3,d:4,e:5}) console.log(value)
» undefined
"a"
"b"
"c"
"d"
"e"
« for (value of {a:1,b:2,c:3,d:4,e:5}) console.log(value)
× TypeError: ({a:1, b:2, c:3, d:4, e:5})['@@iterator'] is not a functionEarlier quoted context omitted.
I can't speak for others, but if you write browser apps/websites for a generic audience you basically have no choice. The reason consist of two letters: IE
But IE didn't support SVG either until recently? If I read right, it was supported since the same version as HTML5 canvas (IE 9), http://caniuse.com/#cats=SVG http://caniuse.com/canvas
Earlier quoted context omitted.
I can't speak for others, but if you write browser apps/websites for a generic audience you basically have no choice. The reason consist of two letters: IE
But IE didn't support SVG either until recently? If I read right, it was supported since the same version as HTML5 canvas (IE 9), http://caniuse.com/#cats=SVG http://caniuse.com/canvas
[UPDATE: also I was reading SVG/DOM as an or]
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…
As a person who works on a JS engine I can say that a lot of the speed up in this library is the failure to handle holes correctly - it's surprisingly expensive to do a hole check, although there's still room in most engines to optimise it, those checks are fairly time consuming :-/
So I always putting this into not-done-yet category for JS VM related work and it is a very interesting problem to tackle.
Here's a jsperf of fast.js / lodash / native: http://jsperf.com/fast-vs-lodash
Earlier quoted context omitted.
Note that 'in' for (key in object) is for getting keys, in Firefox, meanwhile 'of' for (value of iterator) is for getting values out of an Iterator.
the only issue is i'd like to differentiate between iterating arrays and objects at the syntax level. Coffeescript uses `in` for arrays and `of` for objects, but I agree that becomes confusing. Open to other suggestions!
But if Coffescript can walk away with its choice then I don't think you'll have anything to worry about.
Here's another one for you, one of my favorites that used to be drastic: http://jsperf.com/pipetrunc blah | 0; // fast! Math.floor(blah); // slow(er)! (except on FF nightly) Caveat: Only works with numbers greater than -2147483649 and less than 2147483648.
Microbenchmarks like that require a lot of care to measure something correctly. Check out my talk from LXJS2013 for more details: slides http://mrale.ph/talks/lxjs2013/ and video https://www.youtube.com/watch?v=65-RbBwZQdU