Coders

Standard fare for most dynamic data and the way most everybody would tell you to do it. Only thing is that it scales like a dog.

The thing is that holding all the weather of the entire globe in memory, well, takes a lot of memory. More than is reasonable. In which case, there’s a fairly decent chance that a given request can’t be served from the cache, resulting in a query to the database, an update to the cache, which bumps out something else, in short, not a very good hit rate.

If we were able to make our clients in London perform an HTTP GET on http://weather.myclient.com/UK/London then we could return headers in the HTTP response telling the intermediaries that they can cache the response for an hour, or however long we want.

I frequently see bare queries from programmers in discussion forums, especially from new programmers, who are worried about performance. These worries often stem from popular notions about what operations are "slow." Division. Square roots. Mispredicted branches. Cache unfriendly data structures.

Inevitably someone chimes in that making out-of-context assumptions, especially without profiling, is a bad idea. And they're right.

The golden rule of programming has always been that clarity and correctness matter much more than the utmost speed. Very few people will argue with that. And yet do we really believe it? If we did, then 99% of all programs would be written in something like Python. Or Erlang.