

Grinch about the array.length caching - dmit
http://mrale.ph/blog/2014/12/24/array-length-caching.html

======
jwmerrill
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...](http://books.google.com/books?id=ED6ph4WEIoQC&lpg=PA64&vq=there%20are%20several%20operations%20happening%20each%20time&pg=PA64#v=onepage&q&f=false)

~~~
mraleph
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](http://mrale.ph/irhydra/2)

~~~
jwmerrill
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...

~~~
mraleph
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.

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

Wow, cool!

