back
5 comments
The first place I got the impression that it was a good idea to cache the array length and/or reverse loops was in Zakas, "High Performance Javascript" [1]. The book was written in 2010, and I have a feeling that compiler advances have laid waste to huge swaths of it. Some of it may have already been outdated when it was written. Even so, performance folklore is slow to disappear.

I've found everything that Egorov (author of this post) has written is well worth reading.

If there's one overall theme of his work, it's that it is generally highly unreliable to extrapolate the result of micro-benchmarks to real code. Instead, you need to measure potential optimizations in your actual code base. And you might need to do it again next year, because compilers are constantly changing and usually improving.

If there's a second overall theme, it's that you can and should examine the code that your JS compiler is producing, rather than relying completely on black box benchmarks. It would be great if browser dev tools would make this easier to do directly. Currently, I find the external tools for doing this hard enough to set up and manage that it isn't really very economical to do this kind of analysis frequently.

Compare to Julia, where you can call code_llvm(fn, (argtypes...)) to see the LLVM IR of a piece of code right from the REPL, or code_native(fn, (argtypes...)) to see the generated machine code for your architecture.

[1] http://books.google.com/books?id=ED6ph4WEIoQC&lpg=PA64&vq=th...

Thanks! You are absolutely correct in summarizing two underlying themes for my microbenchmarking related posts: (a) one needs to understand what one is measuring (b) one needs to understand if that actually matters for their project.

> Currently, I find the external tools for doing this hard enough to set up

I have tried making this kind of information easier to grok for JavaScript developers by creating IRHydra[1]. Please reach out and describe your issues - one of the reasons why something like IRHydra is not part of Dev Tools yet is that Dev Tools people are not registering big demand for indepth analysis tools.

[1] http://mrale.ph/irhydra/2

IRHydra is awesome, but there is still a lot more friction to using it compared to the built in dev tools. You have to run v8 with special flags and upload files to a web page. In some ways, this is still quite simple compared to getting rolling with debugger/disassembler tools for many other languages/environments.

But imagine a workflow where I'm profiling my real application in the browser, and I see that some function comes up hot. If I could just click its name and get this kind of information, I believe I would do this kind of analysis much more often.

That said, as a person who makes websites, I'm sensitive to the fact that people who claim they would use a feature if you built it won't actually always use the feature when you build it...

I totally agree with you! I would love to have equivalent functionality built right into Dev Tools. Immediacy is a very important aspect of usability - I would like to inspect a running program without any special movements.

> upload files to a web page.

Minor clarification: nothing ever leaves your local computer. There is no server component in IRHydra. It's purely your browser that interprets these files.

> nothing ever leaves your local computer. There is no server component in IRHydra.

Wow, cool!