Hacker News Reader

Try/catch/finally is handled by TurboFan (one of V8's optimizing compilers) - see https://groups.google.com/forum/#!topic/v8-users/maH60gh_a8s for more detail. There is a certain set of features which go through TurboFan instead of CrankShaft (the other optimizing compiler).

Disclaimer: I work on the V8 team.

Still, using `try` seems much slower (in Chrome 52):

    var times = [[],[]]
    var sums = [0, 0]
    var funcs = [
        function(){     sums[0]+=1            },
        function(){try{ sums[1]+=1 }catch(e){}}
    ]

    function bench(n){
        var t0 = performance.now()
        for(var i = 0; i< 30000; i++) funcs[n]()
        times[n].push(performance.now()-t0)
    }

    for(var j = 0; j< 10000; j++) bench(j%2)

    function avg(ary){return ary.reduce(function(acc, v){return acc+v}, 0)/ary.length}

    console.log(times.map(avg))

    // results: 
    //         [bare             , wrapped in try{}  ]
    // VM89:18 [0.347546000033617, 0.7464809999451041]

Let's do some more work inside the function / try block:

    var times = [[],[]]
    var sums = [0, 0]
    var funcs = [
        function(){     for (var i = 0; i < 1000; i++) sums[0]+=1            },
        function(){try{ for (var i = 0; i < 1000; i++) sums[1]+=1 }catch(e){}}
    ]

    function bench(n){
        var t0 = performance.now()
        for(var i = 0; i< 30; i++) funcs[n]()
        times[n].push(performance.now()-t0)
    }

    for(var j = 0; j< 10000; j++) bench(j%2)

    function avg(ary){return ary.reduce(function(acc, v){return acc+v}, 0)/ary.length}

    console.log(times.map(avg))

    // results: 
    //         [bare               , wrapped in try{}  ]
    // VM90:18 [0.09457900004982948, 0.5069960000008344]

I'm sure I'm doing many things wrong since I'm not a JS perf expert, but still, the difference here is goes from 2 to 50 times slower with the `try` block...

Edit: for the sake of completeness, on the same machine:

Firefox gives [10.2, 10.3] and [5.30, 5.45]

Safari gives [5.56, 5.60] and [4.91, 4.94]

> So you kind of get a catch 22 where V8 won't spend time to fix it because it's not worth it, and it won't be worth it because V8 doesn't support it.

That's an easy fix though: introduce one or more performance tests that stress try/catch (i.e. don't employ the workaround). Obviously Google won't be doing it, but there's nothing to stop Microsoft or Mozilla for lobbying for it.

Is it an easy fix though? It seems necessary, but not sufficient, to build an open source, cross platform JavaScript engine that integrates with node.js, just to be able to advocate for the benchmark change to be made.

That seems like a non-trivial task. Though luckily (for the JS community) they've been working on it.

Happily, they've thought about this stuff already:

"Continuing to invest in understanding and improving real world performance is a priority for the team. Going forward, we also want to work with the benchmarking workgroup[0] and the community to identify real world performance scenarios for Node.js." [1]

[0] - https://github.com/nodejs/benchmarking

[1] - https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakra...

    > Most of them talk about how you should avoid try/catch in
    > performant code, even though it's only one engine that doesn't
    > optimize it

That still sounds like great advice even though it's "only" slow on one engine. Very few performant JS applications have the luxury of not worrying about how Chrome performs, as opposed to only IE, Firefox & Safari.

Oh it is great advice right now, since Chrome has such large market share and V8 is the only "real" engine on the back end at this time, you'd be dumb to ignore it.

My point was that you want multiple competing engines to avoid this kind of thing going from a "V8 thing" to a "Javascript thing".

Right now V8 can still fix this "issue" and going forward that will no longer be a problem, but if history was a little different, we could have ended up with no engines that support an optimized try/catch since nobody uses it, and nobody would use it because no engines supported optimizing it.

The problem is that perf tips have a strong tendency to become "cargo cult knowledge" that keep getting passed around even though no one knows the original reason for their existence, or that they have long since stopped applying. This has been a problem in the C world for ages, and now it looks like it's coming to JavaScript as well. Even if Google were to fix this issue tomorrow, we'd probably still see programmers in 2025 writing convoluted code to avoid try/catch because "it's bad for performance, I heard that somewhere".

If Microsoft had released Chakra around the same time, it never would've been an issue, because people would've known "Oh, this is just Google's bug", gotten on their case to fix it, and it would've been gone a long time ago.

> If Microsoft had released Chakra around the same time, it never would've been an issue, because people would've known "Oh, this is just Google's bug", gotten on their case to fix it, and it would've been gone a long time ago.

But this is the exact situation that the browser world is in (V8 is only one vendor among many) and that hasn't come to pass.

True, but one way to push them to fix their engine and make it better is for them to feel pressure to not be left behind. People are going to code in the way that makes sense for them, and if one mainstream-enough implementation works way better than another, eventually people are going to stop bothering with it.

Safari has become the new IE in a lot of ways, and larger and larger websites/apps are starting to only target Firefox and Chrome, leaving Apple with the options to either give up or rejoin the mainstream.

Huh, I'm a little surprised that the try/catch de-optimization is still a thing. I watched a v8 optimizing compiler talk maybe ~4 years ago when this was discussed.

Wasn't the workaround to do nothing in the try/catch body aside from calling a named function defined outside the function scope where the try/catch was defined?

Yeah, you can basically turn try/catch into something that looks like the promise constructor and pass in a "try" function and a "catch" function, and then everything is optimized well (for the most part, this can still prevent some fancy optimizations).

> Huh, I'm a little surprised that the try/catch de-optimization is still a thing.

It's fixed in Turbofan, but that's not shipping yet.

TurboFan is shipping for functions with try/catch or try/finally.

>Just look around at most javascript "performance tips". Most of them talk about how you should avoid try/catch in performant code, even though it's only one engine that doesn't optimize it, and they have talked about how they want to fix it, but just haven't

Well, if that engine is dominant or even just a 20%+ player (like V8 is), the advice still holds, whether there are 2 or 5 other engines.

That's true client-side. The push here seems to be Chakra for Node, and if Chakra is more performant for certain Node workloads, then you could see Chakra on Node being adopted on that basis alone.