Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike’s Rules of Programming (1989)

users.ece.utexas.edu

Post reply on HN
Print view View original

221–230 of 332 posts

Re: Rob Pike’s Rules of Programming (1989)

#221

Post by hansvm »

dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

No comment on your particular example, but the opposite approach is more common than I'd personally like and also not ideal -- if you're doing anything nontrivial it's probably worth doing a back of the envelope calculation to ensure you have enough disk, memory, and network throughput for your favorite solution to handle the expected load.

Re: Rob Pike’s Rules of Programming (1989)

#222

Post by noisy_boy »

flukus wrote: post #151
maxk42 wrote: post #133

Earlier quoted context omitted.

This is particularly exasperating for me. I can't tell you how many times in my professional career I've ended up speeding up systems by removing two or three layers of improperly-implemented "caching" and using good ol' MySQL and a basic understanding of algorithmic time complexity to simplify things.

Me too. I've seen a few systems that replaced their simple request requiring 10,000 queries "optimized" by requiring 10,000 cache lookups when they should have just added some joins. The bottleneck is the network latency, not the database. The worst I've seen is an nHibernate cache stored in a session variable, half the database was being serialized/deserialized on every http request. Fortunately that was a small dat…

Having worked with Hibernate recently on a smallish database (that isn't expected to grow too big), my take away is to minimize the network trips. If you have to check something for a list/set of things and all of that can be done from, say, two not so big tables, fetch the superset of records via a join with as much criteria pushed to predicates as efficiently possible and handle rest of the logic in application code. It is so much more quicker. Of course, like most things in software, conditions apply like network latency/total no. of records being fetched by the query/potential for data to suddenly grow etc.

Re: Rob Pike’s Rules of Programming (1989)

#223

Post by yashap »

nojvek wrote: post #217
yashap wrote: post #216

Earlier quoted context omitted.

It’s insane how often people stick Memchaced/Redis in front of MySQL/Postgres, completely unnecessarily. So many otherwise decent developers assume that MySQL/Postgres is too slow/doesn’t scale, without even trying. Or similarly, how frequently people shard databases unnecessarily. A single MySQL/Postgres server, on a beefy machine, can handle an absolutely massive amount of work, with great performance, assuming you…

I don’t think people realize that databases themselves have a caching layer internally. Redis isn’t magical, you still have to send network packets to the other server. Even when reading from disk via mmap, hot pages are in memory. Sometimes postgresql is faster than redis because all it needs to do is read something from memory and spit it out in the right format.

Totally. If the hot pages of your indexes and hot pages of your records mostly fit in memory, DBs mostly read from memory anyways. If they don’t mostly fit in memory, things can slow down a bit, but you’re likely better off vertically scaling your DB (more RAM) than adding a cache.

Looking up a normal sized record by id, with good networking in your data centre, takes ~1-2 ms round trip whether you’re reading from Redis/Memcached or MySQL/Postgres, and either can handle massive read load if sized properly. The cache just ~doubles your costs, is one more thing to patch/maintain, and introduces new sorts of bugs/outages.

Re: Rob Pike’s Rules of Programming (1989)

#224

Post by noisy_boy »

vishnugupta wrote: post #145
andrewl wrote: post #5

In The Mythical Man Month Fred Brooks said "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

> Show me your tables, and I won't usually need your flowchart A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger/acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM's ESB whic…

I have learned to spend a good chuck on my effort and focus on data model - it is literally the heart of the application. Once that is done correctly, I've seen that the code almost just falls into place by itself.

Re: Rob Pike’s Rules of Programming (1989)

#225

Post by hnick »

gridlockd wrote: post #85

All this advice against "premature optimization" has created generations of programmers that don't understand how to use hardware efficiently. Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks . Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way…

> Here's the problem: If you profile software that is 100x slower than it needs to be on every level, there are no obvious bottlenecks. Your whole program is just slow across the board, because you used tons of allocations, abstractions and indirections at every step of the way.

Oh this hurts. I work with a system in Perl that is just kinda slow. Too slow to be good but not slow enough to be useless. Slow enough that if it crashes we have trouble getting things reprocessed in a reasonable time, there's no fat built in to our timelines.

Anyway I've profiled it many times and found exactly what you said. Layers and layers of OO soup, functions calling functions calling functions. There are no obvious improvements. It's overhead, not code.

Re: Rob Pike’s Rules of Programming (1989)

#226

Post by ses1984 »

Quekid5 wrote: post #150
ses1984 wrote: post #132

Earlier quoted context omitted.

You've never been on a team with two people with opposing opinions I guess.

Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)? That sounds quite dysfunctional. (EDIT: Sure, nitpicks may differ, but...)

Style yes, formatting no.

Worked with two developers who endlessly argued whether or not we should handle a certain bit of complexity in a certain layer or the next layer over, so we ended up handling it in both layers with the downsides of both.

Re: Rob Pike’s Rules of Programming (1989)

#227

Post by cel1ne »

dkarl wrote: post #126

> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…

> Can't we just let stuff work? I'm no fan of MySQL, but can't we admit that a ubiquitous and battle-tested piece of technology, applied to a canonical use case, on tiny data under near-ideal circumstances, is probably going to work just fine?

I call that "separation of error-domains", meaning trying to find interfaces where you can separate off parts of your application, so debugging gets easier:

Is the bug in the database, or in our code?

Re: Rob Pike’s Rules of Programming (1989)

#229

Post by rumanator »

Quekid5 wrote: post #150
ses1984 wrote: post #132

Earlier quoted context omitted.

You've never been on a team with two people with opposing opinions I guess.

Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)? That sounds quite dysfunctional. (EDIT: Sure, nitpicks may differ, but...)

> That sounds quite dysfunctional.

No,it doesn't. It sounds like the expected outcome of not enforcing an established style with automated tools.

All it takes is someone posting a merge request with a bracket out of place, or tabs instead of spaces which screws layout because yes IDEs have custom definitions and a dude happened to have opened a source file with an editor that wasn't properly configured.

Boom, merge request receives two comments pointing out the bracket and how indentation is off.

Congrats, about 20 minutes of your team's day are wasted because that's the time it takes to receive feedback from the merge request, be briefed on the remarks, go through the code and fix whitespaces, commit your change, push those changes, update the merge request, and wait for a team member to review your update.

No drama. No dysfunctional team. No disagreement, even. But those 20 minutes of your life are lost forever.

Re: Rob Pike’s Rules of Programming (1989)

#230

Post by mturmon »

gridlockd wrote: post #154
byronr wrote: post #149

Earlier quoted context omitted.

> Rob Pike probably has never written a program where performance really mattered Rob Pike has written window system software which ran in what now would be called a "thin client" over a 9600 baud modem and rendered graphics using a 2MHz CPU. He probably knows a thing or two about performance tuning.

By "rendered graphics" you mean "place characters on screen"? If the bottleneck for that is a 9600 baud modem throughput, there's not a lot you need to optimize, even on a 2MHZ CPU. Also, having programmed more constrained systems decades ago doesn't magically make you knowledgeable on performance on modern hardware with completely different capabilities. In fact, it's probably what causes you to develop a "computers…

Your reply here saddens me.

I suggest you look up Rob Pike and reconsider some of your hypotheticals about what he knows about. (https://en.wikipedia.org/wiki/Rob_Pike)

Post reply on HN