

JavaScript's sweet spot - paufernandez
http://blog.mrale.ph/post/12396216081/the-trap-of-the-performance-sweet-spot

======
mbq
The 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 <canvas> over SVG. R is from an
another world, but it is a perfect example how this idea can work very well.

------
christkv
awesome article and a good balance between the "possible" speed of js vs the
sacrifice you make in code quality to get that speed.

~~~
mraleph
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)]

~~~
christkv
but for some very narrow hotspots in your code it can mean a massive
difference :)

------
ender7
What kind of performance increases could we see if we simply added type
annotations to Javascript? Would this give the VMs a significant boost?

Something like AS3 (Harmony) syntax:

    
    
      var foo:int = 3;
      var bar:string = "A nice string";
      var baz:Array = ["a", "polymorphous", 4, "array"];
      var v:Array.<int> = [2,3,4];
    
      function f(a:int, b:string):string {
        return a + " " + b;
      }
    

Sidenote: I really want someone to write a Coffeescript compiler that supports
type annotations like the above. It can strip them out when it compiles the
code; I just want it to yell at me if I violate one of my declared types.

~~~
mraleph
It really depends on the semantics of those annotations.

For example: how is v:Array.<int> enforced (and is it enforced at all)?

Type annotations can be a good to seed type inference analysis or adjust
collected type feedback. But unless they guarantee stability of objects shapes
(e.g. Array.<float> can contain only floating point numbers) they'll give
little.

------
Sigma0
This 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.

~~~
mraleph
emscripten generates very similar code from LLVM bitcode which in turn was
generated (optimized) from say C or C++.

It's next to impossible to emit such code from language that is not statically
typed.

Also it's not necessarily going to be faster than handwritten "human"
JavaScript. There are a lot of factors in play. That's exactly what I am
trying to stress in the blog post.

~~~
masterj
I think the OP was suggesting that another language could be used for this
purpose, similar in function to CoffeeScript in that it compiles down to
JavaScript, but statically typed (or even just straight C). That way most of
your app could be written in CoffeeScript or JavaScript, but for those few
functions who's performance REALLY matters, you could reach for a different
tool that makes writing this inhumane but performant flavor of JavaScript
easy.

It's an interesting idea, and having little to no knowledge of compilers, I'd
be interested in your take on it. Could emscripten already be used for
something like this?

------
Peaker
Good article. I strongly disagree with this though:

> And implementation complexity is the worst kind of complexity in the world:
> it leads to subtle bugs that occur on 0.000001% of programs, it leads to
> unpredictable and hard to analyze performance, it leads to volumes of
> rulebooks that specify how to appease the compiler

Implementation complexity is much better than interface complexity. It does
not necessarily break down subtly. Unlike interface complexity, it is
localized.

~~~
scubaguy
Android (VM based language) has the following API:

public View getDropDownView (int position, View convertView, ViewGroup parent)

convertView - the old view to reuse, if possible. Note: You should check that
this view is non-null and of an appropriate type before using. If it is not
possible to convert this view to display the correct data, this method can
create a new view.

The presence of the unintuitive 'convertView' object is caused by the
underlying VM and the unpredictable GC nature. This demonstrates that
implementation complexity can lead to a complex interface.

IMO the design of the interface is an implementation. A language that is
complex to implement will lead to complex interfaces.

------
Srirangan
>> 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.

~~~
mraleph
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.

------
wickedchicken
is the author a C programmer or a C++ programmer? naming a struct 'Point' is
suspicious (instead of 'point' or 'POINT')

~~~
mraleph
yeah, I am sorry, I did not follow C naming etiquette to the letter. You are
right: these days I am a bit accustomed to starting struct's names with a
capital letter because I do a lot of C++ programming.

(I would not call the struct POINT though because it would feel like something
from WinAPI :-))

~~~
wickedchicken
;p

