211–220 of 332 posts
Earlier quoted context omitted.
It's also often interpreted literally. Premature complex optimization is a bad idea, but simple (read, cheap to code) optimization for common bottleneck patterns is a perfectly reasonable thing to do.
It's also often (ab)used far too often to justify performing no optimisation at all.
Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…
But adding floating point numbers isn't associative, in general. Sometimes you need to do it the right way to avoid catastrophic cancellation. I guess the key is to know how to deal with things that are only mostly true.
Earlier quoted context omitted.
> I just go with their suggestions. Why though? I am not going to go with suggestions if they make the code less readable for me!
I think the whole world would benefit if we’d make it so that code formatting happened separately from what was committed. Then everyone could have their local checkouts formatted the way they wanted and there would be nothing to argue about in terms of coding style.
> 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…
Example: Google Chrome codebase was allocating lot of std::string and also someone used a Set to check membership of single item. [1]
I mean, if you say like this, many people don't even care about algorithm complexity.
Doesn't help that people want to write Python in the monster that is C++.
https://groups.google.com/a/chromium.org/forum/m/#!msg/chrom...
> 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…
I wish there was a quick remedy for such people. But usually they are new, based on what I said. So they should be Junior Developer, not Architect. Sure, you can suggest things, but the answer is nope.
A lot of people, though, may never get much experience supporting their own architectures, because they swoop in, then swoop out, never staying at a job long enough. Or support gets assigned to another group. One thing I like about Agile is that the team that creates the code is the one that supports it.
> 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…
I’ve worked on some pretty high traffic systems, with pretty large data volumes, and very, very rarely have I actually needed to cache simple DB reads. And it’s hard to properly cache complex ones anyways, because cache invalidation is so hard for complex queries. Likewise, it’s very rare that I’ve needed sharding. SOMETIMES you need these things, but mostly people are adding a lot of extra complexity and cost for no good reason.
> 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…
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…
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.
Also in support of Rule 5, see Eric Raymond's treatment of Data-Driven Programming:
"Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic. See Rob Pike's Rule 5.
"Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data."
http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id...
http://www.catb.org/~esr/writings/taoup/html/generationchapt...
The Data Dominates principle is the key, everything else just follow, including n are usually small and preference for simple algorithms.
Nowadays we have exactly the opposite, which is understandable since the field has been invaded by uneducated amateur posers.
Earlier quoted context omitted.
Worrying about performance of small collections is premature optimization. Using maps or sets nowadays is mostly for clarity, as they are used to solve certain kind of problems.
I agree with you. But what you're talking about is completely different from what I was responding to originally. If you need a set, use a set. But don't assume that its faster than a std::vector. Even then, std::vector has set-like operations through binary_search or std::make_heap in C++, so it really isn't that hard using a sorted (or make_heap'd) std::vector in practice. -------- Even if you don't plan on doing o…
But inserting into sorted std::vector is o(n log n) in worst case right? (As you have to binary search the position and move other elements). But a hash set with linear probing can give O(1) (amortized) access, while usually maintaining an invariant like total_size > 2*n. I don't think that would be such an impact on cache locality. Linear probing doesn't require linked lists.
Of course this is given that you have a data structure in standard library. But at this point I think hash sets are pretty standard.