Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

Parent Full thread

Anyone like physical analogies more? If you convert them into relative masses:

L1 cache: a squirrel (1kg)

L2 cache: a mid-sized cat (~5 kg)

RAM: a tall, well-muscled man (~80kg)

Hard disk: one hundred blue whales (100 * ~130 metric tonnes)

This is what I mean when I say "It doesn't matter how fast your language is, you're just racing to get to wait on I/O faster."

P.S. Let's extend the analogy to include two other common factors:

Typical round trip to database: the combined mass of every ship, plane, and person in the USS Nimitz' air group... with room for another two fleets or so after you're done (150 ms ~ 1.5 million metric tonnes)

Time for user's computer to render a web page of medium complexity: worldwide demand for cement in 2009 (2 seconds = 20 million metric tonnes)

But please, spend time optimizing your string concatenation... because that is going to help ;)

[Edited: Revised and extended because I introduced a conversion error or two and then compounded them. Word to the wise: mental conversion to fractions of blue whales not advisable before morning coffee.]

I prefer the analogy posted by norkakn on reddit: http://www.reddit.com/r/programming/comments/90tge/hey_rprog...

L1 - There is a sandwich in front of you.

L2 - Walk to the kitchen and make a sandwich

RAM - Drive to the store, purchase sandwich fixings, drive home and make sandwich

HD - Drive to the store. Purchase seeds. Grow seeds..... .... ... Harvest lettuce, wheat, etc. Make sandwich.

Amazingly, that still underestimates the ratio of HD/RAM latencies by a factor of 10.

(I'm using 83ns and 14ms, as in the article, and half an hour for RAM and one year for HD.)

Yeah, but if you can have more ram than the commonly accessed data (which is the usual case I have seen, unless you are putting things like photos in the DB. Most of us have databases that are far smaller than 64GiB, and 64GiB ram servers can be had for the value of less than a week of programmer time. ) once the database warms up, the read speed is no longer blocked on disk.

Disk is largely something you keep around so you can handle really large things (like pictures and video) and so that all your data doesn't go 'poof' when you hit the power.

(the other side of that, of course, is that if you want your data to be in good shape after the aforementioned power loss, then yeah, your writes will block on disk speed. But for most people, the 'sane but not correct' default of ext3 and the like is good enough.)

"It doesn't matter how fast your language is, you're just racing to get to wait on I/O faster."

But it does matter how small your runtime (and inner loops) are, if you want to live in the L1 and L2 cache and avoid paying the RAM latency penalty.

I think you are using different numbers from those depicted in the graphic, in which RAM is "only" 83 times faster than L1 cache, or under a kilogram if we go with the L1 hummingbirds @ 10g, and the cat would be 47 grams.

Maybe you meant to start with 1 kilogram? : D

Gah, I really need to put my numbers on paper when doing repeated conversions or errors creep in. You're right, it is pretty borked. Give me a second...

> Give me a second...

L1$: a second

Hard disk: more than five months

That really is incredible isn't it. I don't mind saying I have difficulty comprehending - really comprehending - such large magnitudes.

Great to hear it in different formats though. I can stare at numbers all day and still not really get it, but the difference between a second and 5 months is as subtle as a punch in the nose. Good stuff.

Okay, so, if your DB all gets paged into RAM, what tends to be the next mole to whack in the optimization whack-a-mole?

What sort of app are we talking about? If it is a web app, and you're optimizing the DB... are you sure you're not already working on the wrong mole?

Take a look at the above scale: page rendering times are going to dominate everything else. There are simple, repeatable, effective ways to reduce them. See the presentations from the YSlow guys.

key. I mean, all my experience is with squid, but there are many, many caching proxies. Using caching proxies is a ridiculously easy way for a SysAdmin to take a slow webapp and make it fast without screwing with the application code.

Unfortunately most webapp developers don't use reasonable cache control headers. Most php apps, if your proxy does a HEAD to see if it should re-pull content, render a full page and throw it away except for the headers. (this may be false now, but when I did this, they were using php3. In php3, to handle HEAD requests properly you'd have to actually write code to handle it, which most programmers did not.)

Still, my experience has been that using something like squid gives you a pretty massive performance advantage, even when your webapp is uncooperative.

Business model.

Ding!

But please, spend time optimizing your string concatenation... because that is going to help

I have been a "hero" many, many times by doing exactly this, unfortunately for the assessment of "average" programming knowledge in corporate IT.

How can you optimize concatenation? (seriously - never thought of this as a major performance consideration)

In Java you can use StringBuffer.append() instead of "string a" + "string b" which is nanoseconds faster, allegedly...

Actually, the more important factor here is memory consumption. When you do lots of string concatenations, you end up with tons of unused strings, eating up memory. Also that translates to CPU time the garbage collector has to spend.

Using StringBuffer, although it looks a bit crappy in the code (IMHO), actually does result in massive gains in terms of performance.

"Massive gains"? Really?

That's been my experience, yup. I can't remember if I have numbers/graphs anywhere, but it made a massive difference on a few occasions (If you do a lot of concats).

"Massive gains"? Really?

Find a way to turn concatenating n strings (of a given length distribution) from taking O(n^2) time to O(n) time.

Reply on news.ycombinator.com