3 ms·

The second code comparison is supposed to point out that the second version. Unfortunately, still not easy enough to read to avoid bugs caused by javascript's

The second code comparison is supposed to point out that the second version. Unfortunately, still not easy enough to read to avoid bugs caused by javascript's "unique" approach. `findSmallestPositiveValue([2,11])` gives the wrong value for the supposedly better function. > Even if the second function takes twice as long as the first, we are in the realm of nanoseconds. How can you possibly know this? You can make either function take arbitrarily long by increasing the size of the input. The second one scales worse. I see no reason to assume an upper bound on the input size given. If you want the behavior to be obvious at a glance, just name the function what it does. Just like it already is. Or leave a block comment. The argument here is that javascript is so fast that it doesn't matter what you write because you don't have to worry about that. I just don't know how to reconcile that with the fact that I regularly see websites that have noticeably slow javascript "startup" times.

JoeBot3000 5y ago
> You can make either function take arbitrarily long by increasing the size of the input. The second one scales worse. I think this is the point, the second one scales worse - absolutely (ignoring the bug you mentioned) however it really is more readable, and because V8 is so fast, why not use the second version? Block comments and function names are important, but if someone needs to modify the code to add or change functionality nothing beats simple & readable code.
- recursive 5y ago
  You can use .reduce((acc, curr) => curr > 0 && curr < acc ? curr : acc) and have the best of both worlds. In some cases, there are persuasive arguments to favor readability over performance, but I don't find this particular example very convincing.
JoeBot3000 5y ago
> I regularly see websites that have noticeably slow javascript "startup" times. True, same as any language or applications fast CPUs shouldn't be a free chance to completely ignore writing efficient code. Although I bet those websites are slow because they are doing silly things like adding 1000 items to the DOM one by one rather than being slow because someone didn't optimize their use of .forEach()
inDigiNeous 5y ago
These probably have nothing to do with the speed of javascript as-is, but the whole stack of data and layout of a page that needs to be either loaded from some database and then computed how to layout in a reactive manner. Javascript is very fast, but what is not fast is the frameworks that use it or the ways people use those frameworks. If people with similarly minded thinking as those who develop desktop only apps with native languages, would write javascript only apps, I would say the performance would be very close. But many developers have no understanding of how to write performant code, as they have used to just using some heavy frameworks that handle all that stuff for you, so easily you become limited by that thinking. That is at least my view into this world, where naive web-developers who have like 2 years of software development can get to deploy stuff to production. Iteration speeds need to be fast, so a lot more people are employed without the skills to really understand what is happening, thus resulting in poorly executed services. Or maybe it's just not a priority. Also, many technically inclined people just don't get it, that what is important is that you can execute a function, the speed is not really so important in the end, even though we would like it to be. We tend to live in a bubble, those who have dwelled deeper into the operating ways of computers, that we think that everybody else is like that too, or should be. Many are just doing their jobs, and that does not include learning how a CPU or memory works, but it might be limited to learning how a Vue.js framework works or how to use React.
galaxyLogic 5y ago
> websites that have noticeably slow javascript "startup" times. Doesn't that just mean it can take a long time for the browser-application to download all of its scripts? That can certainly take a long time but it depends on 1) The speed of the web-server(s) serving those scripts 2) The speed of the network you are connected to So web-sites taking a long time to execute their JavaScript on your PC in the browser does not say much about the speed of JavaScript the language. But it is a practical concern of course. Which brings to my mind the fact that JavaScript programs can exhibit extreme parallelism, because they can execute in millions of browsers at the same time, think SETI-search, or unauthorized crypto-mining. So in practice JavaScript can have a huge computational throughput, in other words great speed, because it can execute on multiple clients at the same time, easily.
- pjscott 5y ago
  JS startup time also includes parsing the code and (initially) running in a very low-optimization mode, usually a bytecode interpreter, while the VM gathers profiling data in preparation for later JIT compilation of hot spots. This can be a serious hit to page load times even when all scripts are cached.

JoeBot3000 5y ago

> You can make either function take arbitrarily long by increasing the size of the input. The second one scales worse. I think this is the point, the second one scales worse - absolutely (ignoring the bug you mentioned) however it really is more readable, and because V8 is so fast, why not use the second version? Block comments and function names are important, but if someone needs to modify the code to add or change functionality nothing beats simple & readable code.

recursive 5y ago
You can use .reduce((acc, curr) => curr > 0 && curr < acc ? curr : acc) and have the best of both worlds. In some cases, there are persuasive arguments to favor readability over performance, but I don't find this particular example very convincing.

JoeBot3000 5y ago

> I regularly see websites that have noticeably slow javascript "startup" times. True, same as any language or applications fast CPUs shouldn't be a free chance to completely ignore writing efficient code. Although I bet those websites are slow because they are doing silly things like adding 1000 items to the DOM one by one rather than being slow because someone didn't optimize their use of .forEach()

inDigiNeous 5y ago

These probably have nothing to do with the speed of javascript as-is, but the whole stack of data and layout of a page that needs to be either loaded from some database and then computed how to layout in a reactive manner. Javascript is very fast, but what is not fast is the frameworks that use it or the ways people use those frameworks. If people with similarly minded thinking as those who develop desktop only apps with native languages, would write javascript only apps, I would say the performance would be very close. But many developers have no understanding of how to write performant code, as they have used to just using some heavy frameworks that handle all that stuff for you, so easily you become limited by that thinking. That is at least my view into this world, where naive web-developers who have like 2 years of software development can get to deploy stuff to production. Iteration speeds need to be fast, so a lot more people are employed without the skills to really understand what is happening, thus resulting in poorly executed services. Or maybe it's just not a priority. Also, many technically inclined people just don't get it, that what is important is that you can execute a function, the speed is not really so important in the end, even though we would like it to be. We tend to live in a bubble, those who have dwelled deeper into the operating ways of computers, that we think that everybody else is like that too, or should be. Many are just doing their jobs, and that does not include learning how a CPU or memory works, but it might be limited to learning how a Vue.js framework works or how to use React.

galaxyLogic 5y ago

> websites that have noticeably slow javascript "startup" times. Doesn't that just mean it can take a long time for the browser-application to download all of its scripts? That can certainly take a long time but it depends on 1) The speed of the web-server(s) serving those scripts 2) The speed of the network you are connected to So web-sites taking a long time to execute their JavaScript on your PC in the browser does not say much about the speed of JavaScript the language. But it is a practical concern of course. Which brings to my mind the fact that JavaScript programs can exhibit extreme parallelism, because they can execute in millions of browsers at the same time, think SETI-search, or unauthorized crypto-mining. So in practice JavaScript can have a huge computational throughput, in other words great speed, because it can execute on multiple clients at the same time, easily.

pjscott 5y ago
JS startup time also includes parsing the code and (initially) running in a very low-optimization mode, usually a bytecode interpreter, while the VM gathers profiling data in preparation for later JIT compilation of hot spots. This can be a serious hit to page load times even when all scripts are cached.