Language performance doesn’t matter when a database is involved

17Apr/072

Language performance doesn’t matter when a database is involved

All of the latest Rails/Twitter performance bruhaha made me think about some advice I got a long time ago and that I dish out whenever someone asks me about some performance concerns they have with their code.

Nothing else matters once you hit the disk. Once you do any kind of activity that involves reading/writing to a hard disk, that activity instantly becomes your greatest performance drag. No matter how slow any language is at interpreting/JITing/compiling, it’s still orders of magnitude faster than interacting with a hard disk with physical, moving parts.

Filed under: Database, General, PHP, Rails, Technology Leave a comment

http://sqlservercode.blogspot.com/ Denis the SQL Menace

You don’t necessarily hit a disk when you access a database.
A database tries to store as much as possible in RAM (cached in the buffer)
If a query is hot (meaning the same query is executed over and over again it moves to the front of the buffer, if it is cold it moves to the back until it drops out of the buffer)
This is why DBs need all that ram that they can get

Denis
http://www.lazycoder.com Scott

Good point Dennis, But it’s darn near impossible for the application to know when it’s hitting cache and when it has to read from the disk. In my opinion, it’s better to assume that the database will have to read from disk. That way, if your query is still cached your performance will be optimal.

Speeding up the ruby interpreter won’t help if the database queries aren’t optimized. Even a C++/Java/.NET application won’t be very fast if it is hitting the database multiple times with queries that require table scans and use a new connection each time, negating any connection pooling advantage.