0

After having lots of discussions and back-and-forths about whether or not a change will help/hinder performance, I'm looking for one of the following:

  1. A comprehensive analysis of the performance of various operations broken down by environment and other factors. Something that can tell me things like:
    • Performance difference between a closure vs. a bind
    • The cost of creating an anonymous object for passing parameters vs. passing parameters directly
    • The overhead of making things asynchronous (Promise vs. direct call vs. setTimeout vs. async)
  2. The above, but not necessarily for all environments / situations. Mostly looking for nodejs / v8
  3. A good way to assess these things on my own (is jsperf still a thing?)

Can anyone help me out here?

darpa
  • 990
  • 1
  • 6
  • 16
  • 1
    How would jsperf test your node code? And no. Do the change to your actual code, test the perf before/after. Testing stuff in isolation is misleading in the extreme, and changes all the time. Look at the revolving door of advice around string concatenation circa 3-5 years ago. – Jared Smith Feb 20 '18 at 17:28
  • 1
    Also note that `Promise.then` and `setTimeout` are not the same thing at all, Promise callbacks run during microtask resolution whereas `setTimeout` has to wait at least one event loop. It's a little murkier for `rAF`. – Jared Smith Feb 20 '18 at 17:32
  • 2
    SO have you looked at the built in profiler in node and browsers? Seems like a logical place to start. – epascarello Feb 20 '18 at 17:32
  • Also this: "setTimeout vs. async" isn't really a thing. Javascript is single threaded. There are no "async" operations, not really. In the end it's basically a setTimeout trick to push the function execution to the bottom of the stack. – gforce301 Feb 20 '18 at 17:33
  • 1
    @gforce301 'async' and 'multithreaded' aren't the same thing at all. JavaScript (and node.js in particular) is definitely async. You're confusing concurrency with parallelism. – Jared Smith Feb 20 '18 at 17:33
  • 1
    `Javascript Performance` Your thinking of this the wrong way round, unless your a total moron when it comes to development, the difference between `Promise` / `Callback` etc etc is irrelevant,. Just don't worry about it. Try and concern yourself in writing good code. If you find a bottleneck in performance then come back to to it, do not try preemptive optimisations it's a waste of time. Easy to read and understand code is far more important. – Keith Feb 20 '18 at 17:35
  • @JaredSmith See this SO accepted answer: https://stackoverflow.com/a/748189/1819684. "in the context of computers this translates into executing a process or task on another "thread." You can't have truly async code on a single thread, by definition. Thanks for playing. – gforce301 Feb 20 '18 at 17:37
  • @Keith the difference between callbacks and Promises is not irrelevant, it *changes the execution order*. – Jared Smith Feb 20 '18 at 17:37
  • @gforce301 that answer [is wrong](https://en.wikipedia.org/wiki/Asynchrony_(computer_programming)). Thanks for playing. – Jared Smith Feb 20 '18 at 17:38
  • @JaredSmith I think your missing the point.. :) – Keith Feb 20 '18 at 17:39
  • @Keith not necessarily, totally agreed with the rest of your comment (you always have to consider what they *don't* say) :) – Jared Smith Feb 20 '18 at 17:39
  • @JaredSmith You're link makes my point "without the program blocking to wait for results". Run any intensive, time consuming operation in your "async" handler and watch it block on the SINGLE THREAD. Have fun with that. – gforce301 Feb 20 '18 at 17:43
  • 1
    @gforce301 thank you for pointing that out. I will promptly inform the creators of the XMLHttpRequest that they misnamed the option in the constructor. I will also inform the authors of the HTML 5 spec that the attribute on script tags was misnamed, and also the TC39 with the async keyword for functions. Thank you for correcting these horrible mistakes. – Jared Smith Feb 20 '18 at 17:50
  • For instance, mistakes like [this](https://stackoverflow.com/a/8989174/3757232) and [this](https://www.sohamkamani.com/blog/2016/03/14/wrapping-your-head-around-async-programming/) and ... – Jared Smith Feb 20 '18 at 17:52
  • @JaredSmith Oh. So it doesn't block? Ever? You're telling me that asynchronous code in javascript never blocks per the definition, ever. Mind showing me proof of that? – gforce301 Feb 20 '18 at 17:52
  • @gforce301 you cannot invent a new definition of async to win an argument. Not even multithreaded means 'never blocks' in the sense that you are using it. Threads can 'block' each other through resource contention. – Jared Smith Feb 20 '18 at 17:56
  • @JaredSmith Also apparently John Resig is clueless and [this](https://johnresig.com/blog/how-javascript-timers-work/) is utter nonsense. – gforce301 Feb 20 '18 at 17:56
  • @JaredSmith I didn't invent a definition of anything. I used the [definition](https://en.wikipedia.org/wiki/Asynchrony_(computer_programming)) you linked. " without the program blocking to wait for results" – gforce301 Feb 20 '18 at 17:58
  • @gforce301 `You can't have truly async code on a single thread, by definition` Threads are one way to execute async code, but not the only way. Computers also have Interupts, (IRQ's), signals etc, . In fact before computers as we know it when they were single core with no threading support, we had async op's. Do any of us remember BIOS's of old, and making sure your NE2000 network / IDE controller card IRQ / IO ports didn't colide with your mouse's IRQ / IO port etc.. :) – Keith Feb 20 '18 at 21:00
  • @Keith I appreciate all of what you are saying. What I'm saying is that javascript uses none of those mechanisms. – gforce301 Feb 20 '18 at 21:22

1 Answers1

1

How to assess minor changes in Javascript Performance?

Write benchmarks for your application and run them from your build process. Keep the results in a database and visualise them so that you can monitor them. This is known as performance management.

Of course, most of the things you asked about are micro-optimisations. Avoid those and focus on writing simple (maintainable) and correct code instead. If you feel you need to optimise performance, try something and measure its effects.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375