Hacker News Reader

Comment by dgudkov | Hacker News Reader

What implication on my RoR programming is supposed to be from knowing that mutex lock/unlock time is 17ns? Especially, if the web site is hosted on Amazon? Should really every programmer know it?

View on HN

The idea is more about knowing the scale of time it takes to help compare different solution. With those number you can see that it's faster to get data in memory from a distant server than to read the same data from disk. In common application that means using disk storage is less efficient that storing it in a database on an other server, since it usually keeps almost everything in memory. It also tells a lot about why CDN are needed if you are serving client worldwide. A ping from North America to Europe will always takes 100+ ms, so having geographically distributed content is a good idea.

>In common application that means using disk storage is less efficient that storing it in a database on an other server, since it usually keeps almost everything in memory.

Depends on the usage pattern. Database servers generally have more memory than end user machines, but not proportionally more: A database serving a million users won't have a million times more memory. (This matters primarily when each user stores unique or low popularity data, otherwise the shared database has the advantage.) Moreover, data stored "on disk" on user machines will, with modern long-uptime large-memory desktops (and before long mobile devices), have a high probability of having the data cached and retrieved from memory rather than disk.

Thus, if the data is accessed a relatively short period of time after it is written (i.e. within a few hours), storing it locally on disk may be faster. (And storing it nominally on disk even though it's all cached may be preferable to storing it in strictly memory either because some minority of users have insufficient memory to store all necessary data in memory, or because the data should survive a loss of power or other program termination.)

Edit: It's also worth pointing out that latency isn't the sole performance criterion. Local disk generally has more bandwidth than network. If you're bandwidth constrained (either at either endpoint, the database or the user device), or either is getting charged by the byte for network access, that can be an important consideration.

>Should really every programmer know it?

This lame comment comes up every time I see something like this posted. You're right. Knowing exact latency numbers is probably not going to change how you program, or how I program, or how most program. But why does it hurt to know? Why refuse to learn a few numbers that give some perspective on your system's limitations?

The other end of this is, for example, a programmer who is unaware that disk seeks take something like 100000x as long as accessing main memory.

(Anyway, the posted link is interesting since it shows these numbers over time.)

What might seem like a lame question to you might seem valid to others.

It is probably a useful exercise for someone who thinks knowing these numbers is useless, to understand why other people don't think they are useless. And in that sense asking the question is valid.

If you're never going to leave your RoR comfort zone then I suppose you don't need to know this. But I'd have no qualms saying that "every programmer should know" these numbers, and that if you don't do anything where they matter, you occasionally should.

mutex lock/unlock time is important for anyone writing code that depends on code that is accessing the same data structures at the same time. If you don't know that there is a considerable cost to writing such code, now you do; and this number can quantify it.

Most of the time it won't matter much, if at all, but if you have app that is not running as fast as you would like then understanding those operation latencies can help a lot in optimising it.

Reply on news.ycombinator.com