Comment by hinkley | Hacker News Reader

Comment by hinkley | Hacker News Reader

Parent Full thread

A lot of my poor opinion on developer opinions dates back to a couple projects where Product and Marketing were begging us for substantial performance improvements and the teams pushed back saying this was as fast as you could expect. I got 2x in the first six months on both projects, and delivered 25% per quarter on one for almost 2 years (that maths to around 8x) before I started to scrape the bottom of my barrel.

It’s predominantly a way to shut down thinking, which is why it’s so often misquoted. Knuth’s version is more nuanced. Theirs is not at all.

As a compromise I got really good at doing optimizations that also improved readability. Things like hoisting and better variable naming combined together can be mistaken for just code cleanup.

I also discovered that keyhole optimizations are more palatable. Which is to say, move the slow bit yo a separate function with a single responsibility. Then do the optimization in a separate commit. Then the other devs don’t have to look at your changes and if they turn out to have a bug, we can always revert the change later. They almost never do, but having the option seems to grease the wheels.

My general rule of thumb is that if you see you can 2x it easily, you can actually get somewhere around 10x with effort, since the presence of that easy 2x means nobody really spent any time on performance.

i got over 800 this way. O(n^2) everywhere and n+1 queries

This sounds like being completely performance oblivious, like an extreme opposite of premature optimisation.

My rule of thumb is that as long as it doesn’t really complicate or convolute the code, write with performance in mind.

My expertise is in C# and sometimes this is as simple as using a hash set or dictionary instead of a plain list.

Other times it’s having a decent understanding of how EF (an ORM) actually works (the static typing benefits of them in C# makes ORMs very valuable when used appropriately) and the cost of round trips to any network host (including a DB).

a hashset was used... then ".Where(x=>x == key).Count() == 0"

"Premature optimization" became a battle cry of the Don't Make Me Think crowd.

As I think back to the people who fought me, the same group didn't like when you refactored code either because now they didn't have the code memorized. But I've found in the intervening years that making code discoverable is much more useful than trying to keep it static because coworkers are always going to need to change shit anyway to implement new features even if that feature is neither Correctness nor Performance. What you don't want is for people to hide logic from you. So if you move logic to a function call, that's fine, because it's still in the same neighborhood. But if you hoist it all the way up into a much earlier part of the call tree, you need to announce that in meetings and maybe in the documentation so people know what's what.

It can go to extremes. Like 100x by going from a dynamic to static language then 100x more adjusting the data structures/algorithm…

Once I got very confused when exactly this kind of 10k x speed up I demonstrated for a problem introduced to me as a business bottleneck then got ignored (I wasn’t on this team, though, but it’s still hard to understand the mentality and incentives there).

I've known about a student, long ago in the '90s, who got to speed up a batch codebase in some bigcorp, as a summer job. The original did basically everything wrong, up to bubblesort. So student diligently cleaned up the mess and got a speedup from multiple hours to a few minutes.

Then he could not get an interview anywhere. After some backchannel communication it turned out he had to remove that experience from his CV, as all employers assumed he was just lying.

To be fair, I would have assumed that too. Occam's razor: in a sea of lying candidates, the next one is probably lying too.

Long long ago I filed a bug against TogetherJ, where I determined empirically that they had a bug with monorepo/separate compilation units that resulted in n^5 time complexity for loading multiple project files at once. For the last data point I started loading it at 5pm one day and then it finished at 11 am the following morning. They gave us a workaround that got it down to around 20 minutes, the patch made it a little bit better than that but that was still a long time.

I'm sure I've found factorial complexity code, at least in the design phase, but that's the worst one I've encountered in the wild.

https://arstechnica.com/information-technology/2013/12/expon...

Nitpick but 25% improvement over 8 quarters is 1.25^8, almost a runtime in 1/6th of the time.

25% faster is 1.33x work done in the same time. What you want is 0.75^7 (almost 2 years) gives you 13.3% of the original time, which is 1/7.5. Only it was more like 25-30% so I rounded up.

Interesting how people interpret the word faster differently.

To you, 2x faster means 2x the work done in the same time, but 25% faster means 1.33x the work done in the same time.

I see this a lot - in software people interpret 50% faster as a 50% reduction in time taken.

If a car is 50% faster, I hope people would universally interpret that as e.g. 20 to 30 mph. But if I asked people how long would a 1 hour journey take if it were 50% faster, I bet a lot would say 30 mins, because it kind of seems like that's what I mean.

50 percent faster is 2/3 time, but yes, prominent people have made this error and even doubled down on it publicly.

When you're asked to meet a time limit, that's time domain, not rate, and so improvements will be reported in the time domain.

Time domain also works for Little's Law, which is the more prevalent measure these days anyway. If you double the throughput of a server you can halve the cluster size and retain the same level of service. Which isn't 200%, it's 50%.

If an object moves across a space 50% faster, it finishes in 2/3 of the time. It's not up for debate, it's not ambiguous. To say anything else is wrong.

> Which isn't 200%, it's 50%.

Okay.

Again, you’re insisting that rate is only ever a matter of quantity per unit time, when most user facing work is measured in time to complete a single task, or batch. There are more users than developers by a vast margin, otherwise we could not sustain our high salaries.

Additionally, in cloud computing we do not give a shit about tasks per second, but cost per day, which is how many CPUs we need for a set of tasks, which from Little’s Law is derived from seconds per task, not tasks per second.

And yet I’m the one who is wrong, apparently.

You're wrong if you are contradicting what is fact, yes. It's also morally wrong to use contrived logic to state big impressive numbers to lay people like you seem to be interested in doing. "We got 100% better performance" when you only reduced latency by half, nevermind throughput, is dishonest. That's the kind of lie you seem to be defending. If I'm wrong then I don't understand the point of your posts.

Performance is for the user. If the user has told you that we have an SLA that requires this operation to complete in 10s, but it currently runs in 30 seconds, and your first set of changes gets it to 15s, what improvement are you going to report to the user?

You're going to report in the time domain. In which case 1/2 off the time is 50%.

One of the benchmarking tools I used to use reported 50k ops/sec -> 200k ops/sec as 75% faster. Which definitely IS wrong but I know how he got there. You see you don't count operations per second, you run the loop ?? thousand times and see how many milliseconds it takes. Then you convert that to ops/sec. If you compare before and after while still in the time domain, that's 75%. But if you report throughput right next to a ratio in the time domain you're gonna have a bad time.

When that tool stopped being maintained, the person who replaced it wisely switched to reporting in multipliers. 4x faster is hard to misinterpret. Though "1.1x slower" is still open to misinterpretation.

My only conclusion from this is that "faster" will be interpreted in different ways by different people. This is actually just a fact and can't be disputed, the evidence is too strong.

It would be even better, in your example, to report "4x ops/sec" or "0.9x ops/sec" rather than faster or slower.

Reply on news.ycombinator.com