All About Recursion and Tail Calls in JavaScript
lucasfcosta.com
All About Recursion and Tail Calls in JavaScript
1–10 of 22 posts
Re: All About Recursion and Tail Calls in JavaScript
#2What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats.
I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visual studio C/C# I always feel like I know what is going on.
Re: All About Recursion and Tail Calls in JavaScript
#3What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats. I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visua…
Google has a lot of content, for example "Chrome DevTools => Analyze Runtime Performance =>
Get Started With Analyzing Runtime Performance" [0].
But an important piece of advice is at the bottom of one of their pages [1]: "Avoid micro-optimizing your JavaScript". Apart from their argument there, keep in mind you are programming for a number of very different runtime environments. An optimization that gives you a big boost in one implementation may slow you down on another one. That is true not just between various vendors but also among runtime versions from the same vendor.
[0] https://developers.google.com/web/tools/chrome-devtools/eval...
[1] https://developers.google.com/web/fundamentals/performance/r...
Re: All About Recursion and Tail Calls in JavaScript
#4What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats. I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visua…
Google has a lot of content, for example "Chrome DevTools => Analyze Runtime Performance => Get Started With Analyzing Runtime Performance" [0]. But an important piece of advice is at the bottom of one of their pages [1]: "Avoid micro-optimizing your JavaScript". Apart from their argument there, keep in mind you are programming for a number of very different runtime environments. An optimization that gives you a big…
Ya but that's like a get out jail free card.
I have been through their stuff. It's very superficial. JavaScript has all kinds of implementation dependent mechanics when it comes to promises/async calls/recursion. And when they are happening together, all I want are two numbers at the end of the process. How long did this take and how much memory did this take.
Re: All About Recursion and Tail Calls in JavaScript
#5Earlier quoted context omitted.
Google has a lot of content, for example "Chrome DevTools => Analyze Runtime Performance => Get Started With Analyzing Runtime Performance" [0]. But an important piece of advice is at the bottom of one of their pages [1]: "Avoid micro-optimizing your JavaScript". Apart from their argument there, keep in mind you are programming for a number of very different runtime environments. An optimization that gives you a big…
Ya but that's like a get out jail free card. I have been through their stuff. It's very superficial. JavaScript has all kinds of implementation dependent mechanics when it comes to promises/async calls/recursion. And when they are happening together, all I want are two numbers at the end of the process. How long did this take and how much memory did this take.
But then you are looking at the wrong thing: You are no logger profiling/debugging Javascript but the Javascript runtime. Those tools do tell you the Javascript part, why do you say "superficial"?
Example (memory profiling with heap snapshots): https://developers.google.com/web/tools/chrome-devtools/memo...
Profiling functions (V8, Chrome, using the CPU Profiler): https://developers.google.com/web/tools/chrome-devtools/rend...
What is missing there, I can see how long each function took, even more so when I combine it with the flame chart?
I assume you are still talking about the Javascript part. What the C++ based subsystem does can be examined using tools for that language on the respective platform.
Re: All About Recursion and Tail Calls in JavaScript
#6Until ES6 which introduces Tail Call Optimization, you can use trampolines.
Small summary code: http://paste.ubuntu.com/24568118/
Re: All About Recursion and Tail Calls in JavaScript
#7What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats. I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visua…
For benchmarking I use nanobench:
https://github.com/mafintosh/nanobench
For debugging llnode is super good:
Re: All About Recursion and Tail Calls in JavaScript
#8What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats. I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visua…
when doing micro benchmarks in JS you are likely to make the wrong conclutions because of JS engine optimizations for example removing code where the result is not used.
the proper way to optimize is to identify bottlenecks and look at cpu and memory profile when running in production. then optimize the the code that would bring the most "bang for the bucks" likely to be found at the top of a flame graph.
when doing the actual code optimizations remove unnecesary abstractions by inlining functions, use native objects, avoid memory, and preallocate/fixed buffers to get rid of GC stops by not creating new objects.
Re: All About Recursion and Tail Calls in JavaScript
#9Until ES6 which introduces Tail Call Optimization, you can use trampolines. Small summary code: http://paste.ubuntu.com/24568118/
Trampoline would make a nice addition to Ramda. Unless I'm missing it under an unexpected name?
Re: All About Recursion and Tail Calls in JavaScript
#10What's the best way to benchmark perf optimizations in JavaScript. I see lot of articles like this with no time and memory usage stats. I would like to hear an answer from someone who has experience using gdb or visual studio while studying performance. Whenever I use the chrome debugger to time anything involving async calls and recursion I have this uncomfortable feeling I am not getting it right. With gdb or visua…
Having worked on this pretty extensively, my preferred method is: (1) make two implementations of the function I'm trying to speed up, (2) add a wrapper so half of that function's calls get sent to each version, and then (3) profile in Chrome and compare the results (particularly the time spent in the two alternate implementations, but overall as well).
I know that's not the gdb-like experience you're looking for, but as far as I've found it's the best approach. The issue is that modern JS engines achieve their speed by tracking what happens at runtime and dynamically re-optimizing hot functions - so microbenchmarks are largely meaningless, and the performance of a given function can hugely affected by code that's far away.
(The above is for everyday. For extreme deep-diving, one can use JS engine tools to see what kind of internal representation your code has been compiled into after it got optimized. In chrome this is done with IRHydra - http://mrale.ph/irhydra/2/ .)