For example, in V8 a try/catch statement triggers the whole function to be deoptimized [1]

Chakra and SpiderMonkey fully optimize these functions even with a try/catch statement (according to 2 devs last time I talked about this [2]).

Without alternate engines, people start to think that implementation details in one engine apply to javascript as a whole.

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 [3].

And that's just one example, there are hundreds of examples of bugs, performance tricks, and even differences in spec interpretation that can cause issues and can inadvertently become a "standard" without multiple competing engines.

[1] More accurately, the function will never be optimized in the first place if it contains a try/catch at all since Crankshaft doesn't support try/catch.

[2] https://news.ycombinator.com/item?id=10896729

[3] IIRC they haven't devoted time to optimizing it because the architecture of V8 doesn't work well with something like try/catch, but also because it's fairly simple to work around, and most people already do. 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.

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.

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.

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.

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?

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

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

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

Additionally, ChakraCore exposes a C API instead of a C++ API, which is interesting because of the relative ease of embedding C APIs in other languages (in my interest, Rust). V8's C++ API is underdocumented and relatively painful.

JavaScript itself also need competition. I really hope the browser vendors can sit down together and start working on a better language for the future browsers.

Otoh, dozens of libraries doing the same thing may be just like dozens of models of fork to eat the soup.

Having alternatives also helps keeping a standard-based platform conformant with the standard and not slowly drift due to various extensions and idiosyncraties being excessively leveraged in an ecosystem.

We also have Spidermonkey and JavascriptCore, nothing has changed.