Talk:Array length

JavaScript

I like the direction of rdm's suggestion about efficiency and the cost of folds (depending of course, on implementation - the Haskell prelude 'last' is a fold). ES6, which has put some work into tail-recursion optimisations, may be a bit better than ES5 as a vehicle for functional styles of code composition.

function last(list, defaultValue) {
   return list.length ?list[list.length-1] :defaultValue;
}

Taking it one step further, I guess one could also argue that, depending on implementation, two calls to the length function, though probably unlikely to involve two scans of the whole array, might also look a bit profligate.

Perhaps just cache it ?:

function last(list, defaultValue) {
    var lng = list.length,
        return lng ? list[lng-1] : defaultValue;
}

Though once we announce the start of the pre-optimisation season, we are probably also inviting someone to pop up and point out, quite correctly, that JS implementations of ternary expressions tend to be less efficient than their implementations of if then else statements :-) Hout (talk) 16:22, 8 October 2015 (UTC)

Yep. And on a related note Haskell's fold optimizations (where non-used elements aren't fetched at runtime) do have a compile time cost.

And it's also possible that different JS implementations will optimize ternary expression handling. But mostly I don't care about optimizations which yield less than a factor-of-2 improvement - with exceptions to the rule, of course, being in the context of resource-critical bottlenecks. Reason being that quite often there's factor of 1000 (or better) optimizations available if you instead take some time to digest the relevant issues. (And the reason for that is that efficiency is not a universal good, but something which relates to a specific effort.) --Rdm (talk) 17:21, 8 October 2015 (UTC)