Super Volatile

Dynamic analysis is a great complement to static analysis: unfortunately, it is not a replacement. An ActionScript program that has been optimized to death by an AOT compiler can, almost trivially, beat a JavaScript program that is optimized on the fly by the JIT compiler. The only way out would be to let the JIT compiler work till death, but that is not an option! Checkmate.

So yes, you will hear about all the great things in V8 (JavaScript VM), including type inference. The fact is, there is no way a JIT compiler can afford to do the kind of modular analysis that an algorithm implemented in an AOT compiler can.

Regardless how arrogant it sounds, it's true. Numbers do follow in the article.

Some specific technical goals are:

• To allow many concurrent HTTP requests to run across a single TCP session.

• To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.

• To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.

• To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
• To enable the server to initiate communications with the client and push data to the client whenever possible.

White paper of SPDY, Google's new protocol to improve and potentially replace HTTP. The latter has served us well, but is not really optimized for speed.

I recently came across a blog article titled Cripple the Google CDN caching with a single character. It was written by David Ward, who's an author of some well-known Javascript books. His main point is that you shouldn't link to the SSL versions of javascript libraries on Google's AJAX CDN because of performance reasons. He claims that browsers don't cache resources served through SSL.

This is a completely incorrect statement.

The article mentioned here scored high on Hacker News homepage, proving that such places are not immune to misguided technical advice. Fortunately, there's always somebody who will nail it down.

I'm using approximate powers-of-ten here to make the mental arithmetic easier. The actual numbers are less neat. When dealing with very large or very small numbers it's important to get the number of zeros right quickly, and only then sweat the details. Precise, unwieldy numbers usually don't help in the early stages of analysis.

Facebook engineer shares interesting hints on estimating scalability of the architecture. Also, illustrates well the power of the bottom-up understanding of the system.

Holy smokes, that was fast! We were able to open a tcp connection, make an http request, receive an 8KB response, and close the connection all in 85ms! That's even faster than I expected, and demonstrates that it should be possible to build an app with a page load time below the threshold that humans perceive as instantaneous (about 150ms, according to one study). Sign me up.

How Google is reducing initial page load of its homepage to 85ms.

One day the Sysadmin realizes that their database is sick! It's spewing bile and red stuff all over! Sysadmin declares it has a fever, a load average of 20! Programmer asks Sysadmin, "well, what can we do?" Sysadmin says, "I heard about this great thing called memcached. It really helped livejournal!" "Okay, let's try it!" says the Programmer.

The best introduction to memcached I've seen (not that I've seen many).

I am amused each time I learn about a completely unnecessary "optimization" that has quietly snuck into one of my programs. These changes happen automatically while programs are being composed, often before they have been run, and almost always independent of profiling. They make programs longer, more difficult to read and sometimes even slower. So why do I write such programs? It is because I, like most programmers, am shockingly bad at intuiting the location of real bottlenecks.

On common phenomena among most programmers. If premature optimization is the root of all evil, then lack of profiling is usually at the root of premature optimization.

it goes right to left

The article is a chaotic chat transcript, but the message is profound for any front-end developer. Also see Steve Souders' article on the subject.

Any savvy web developer can tell you how many kilobytes their code consumes. They bundle, minify, compress and tune the data sent out to within an inch of its life. Wire weight is easy to measure and has a direct impact on your application's launch time. But how many milliseconds does it take the user's computer to parse and load your code once it's arrived? What differences are there between CPUs, operating systems, browsers and plugins? What speed leaks are we overlooking?

A benchmark for JavaScript parsing times.