JavaScript's sweet spot
blog.mrale.ph
JavaScript's sweet spot
1–10 of 19 posts
Re: JavaScript's sweet spot
#2awesome article and a good balance between the "possible" speed of js vs the sacrifice you make in code quality to get that speed.
Re: JavaScript's sweet spot
#3The worse is that people expect such language to perform dumb high-load operations rather than use its expressiveness to conduct chunks of lower-level language to do the dirty job, such as with over SVG. R is from an another world, but it is a perfect example how this idea can work very well.
Re: JavaScript's sweet spot
#4awesome article and a good balance between the "possible" speed of js vs the sacrifice you make in code quality to get that speed.
Well I would not recommend writing code like mr. C to anyone. Unless you really-really-really need every last usec you can get :-)
The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolating speed shown by some project into effectiveness of the whole language.
[also I tried to stress the fact that speed is not everything there is to performance. If you have a long lived webapp in your tab you suddenly might become concerned by memory usage. Which is rather difficult to predict partially because of the "hairy" nature of the heap, the fact that VM tries to adapt to your app but doesn't always get it right, and the cost of the VM itself (e.g. generated code and additional data structures)]
Re: JavaScript's sweet spot
#5>> Suddenly mr. C gets a call from his boss. “We’ve decided
>> to rewrite our apps in JavaScript. It is pretty fast
>> nowdays, ya know.” says the boss and hangs up.
Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
Re: JavaScript's sweet spot
#6>> Suddenly mr. C gets a call from his boss. “We’ve decided >> to rewrite our apps in JavaScript. It is pretty fast >> nowdays, ya know.” says the boss and hangs up. Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
Typo: could realistically not be faster
Re: JavaScript's sweet spot
#7awesome article and a good balance between the "possible" speed of js vs the sacrifice you make in code quality to get that speed.
Well I would not recommend writing code like mr. C to anyone. Unless you really-really-really need every last usec you can get :-) The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolati…
but for some very narrow hotspots in your code it can mean a massive difference :)
Re: JavaScript's sweet spot
#8This is an interesting article with regards to helping the V8 compiler optimise JavaScript code. Often, if C like speed is required, it would be easier to just write C rather than try emulate it through esoteric language features, but I wonder if these kind of compiler optimisations could be included via a language that compiles to JavaScript, such as CoffeeScript, at the expense of readability.
Re: JavaScript's sweet spot
#9>> Suddenly mr. C gets a call from his boss. “We’ve decided >> to rewrite our apps in JavaScript. It is pretty fast >> nowdays, ya know.” says the boss and hangs up. Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
Well... You are underestimating the power of sweet spot :-) In a tight computation kernel it's actually possible for JavaScript or any other JIT compiled language given a good JIT to match the performance of C.
Also mr. C and his boss came into existence for a very particular purpose and that purpose is not "JavaScript vs. C" but rather "Normal JavaScript vs. inhuman JavaScript" comparison.
Re: JavaScript's sweet spot
#10>> Suddenly mr. C gets a call from his boss. “We’ve decided >> to rewrite our apps in JavaScript. It is pretty fast >> nowdays, ya know.” says the boss and hangs up. Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
The boss did not say javascript was as fast as C, but that it was "pretty fast". As in "fast enough", with the advantage of simpler distribution.
And I'd tend to agree, a single order of magnitude difference with C out of the box? That's pretty damn good (it helps that the code is highly numerical, JITs are good at that).