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

Performance excuses debunked

computerenhance.com

Post reply on HN
Print view View original

71–80 of 130 posts

Re: Performance excuses debunked

#71

Post by JanneVee »

kaba0 wrote: post #68
JanneVee wrote: post #67

Earlier quoted context omitted.

The advice is that consider memory layout when doing repetitive operations on your data. > The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in…

I don’t see how OO is at fault here, though.

OO encourages objects graphs scattering your data unpredictably in memory and modern CPU:s likes to have it's data in continuous memory area where it can do prefetching and prediction on where your data resides.

Re: Performance excuses debunked

#72

Post by citrin_ru »

magicalhippo wrote: post #13

There's often a lot of low hanging performance fruits when writing code. Need to loop over some order lines and find distinct article numbers? Use a hash-based set with O(1) access, not just a list which will have O(n). If not you'll end up writing an O(n^2) routine for no good reason, which will work swimmingly on you 10 line test order and cause grief in production. I don't think a lot about performance most of the…

O(1) hash vs O(N) array loop is a bit more complicated - for small N linear search can be faster - no need to compute a hash function, if data stored directly in the array (instead of pointers) then there will be less CPU cache misses. Exact threshold can be determined in a benchmark but the key here here is that N should be bounded - if a user can manipulate N to be huge and you have O(N^2) somewhere in your code it is not only performance but also a potential security problem - a DoS vector.

IMHO the key to not writing silly code is to have a good mental model of how your code works and how it fits into a bigger picture which includes OS, hardware, network and other services (like a DB). This model should be updated from time to time based on benchmarks and metrics from production services but once you have this knowledge it takes almost no additional time to apply this in practice and even if you'll be taking shortcuts to save development time you'll be better aware of this tradeoff.

Re: Performance excuses debunked

#73

Post by gonzo41 »

JanneVee wrote: post #71
kaba0 wrote: post #68

Earlier quoted context omitted.

I don’t see how OO is at fault here, though.

OO encourages objects graphs scattering your data unpredictably in memory and modern CPU:s likes to have it's data in continuous memory area where it can do prefetching and prediction on where your data resides.

That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).

Re: Performance excuses debunked

#74

Post by fredrikholm »

devjab wrote: post #33

Performance matters, but I’m not sure people are saying that it doesn’t. I’m not a performance “first” type of programmer by any means, but I always keep it in the back of my mind, what I also tend to keep in the back of my mind is cost. I recently “inherited” a couple of back-end services when a developer left our company. It turned out that the code was terrible and that they haven’t used, any, or our helper tools.…

I'm not following.

> [bad developer burns a year worth of salary building something that doesn't work]

The cost you cite for the rewrite implies a week or two worth of work. Why did this developer spend an entire year on it?

Really bad developers are really bad, yes. Double work is very expensive.

> I didn’t rewrite it because of its poor performance

> ... massive performance improvement, and it’ll be even better once I finish building the cashing.

So even with the massive performance improvement, you still need to improve the performance even more? It sounds like you would of had to rewrite parts of the system even if it was decently written to begin with.

Re: Performance excuses debunked

#75

Post by joseph_grobbles »

I once was brought into a team that fervently bought into the "hotspot" argument, blustering ahead under the notion that performance was tomorrow's problem where someone would spend a day with a profiler and it would all be fixed.

In reality their project was death by a thousand...neigh million or billions...of cuts. Poor technology choices. Poor algorithm choices. Incompetent usage (e.g. terrible LINQ usage everywhere, constantly). This was the sort of project where profiling was almost impossible because any profiling tool barfed up and gave up at every tier.

Profiling the database was an exercise in futility. Profiling the middle tier was a flame graph that was endless peaks. Profiling the front-end literally crashed the browser. I ended up having to modify Chromium source to be able to accurately get a bead on how disastrously the Angular app was built.

This is common. If performance doesn't matter to a team, it will never be something that can be easily fixed. Maybe you can throw a huge amount of money at the problem and scale up and out to a ridiculous degree for a tiny user base, but making an inefficient platform efficient is seldom easy.

Re: Performance excuses debunked

#76

Post by SPBS »

typon wrote: post #6

I kind of wish Casey would stop making these videos. I'm being completely serious when I say that this kind of knowledge and mindset gives you pretty much a superpower in the industry. Everywhere I go people think I am amazing, even though I just know a few things about performance and low level programming (like, enough to be amazing for "mere mortals", but someone at RAD would snicker at my knowledge). If the indus…

It won't be changing the status quo anytime soon.

Re: Performance excuses debunked

#77

Post by tomgp »

AbsoluteCabbage wrote: post #55
tomgp wrote: post #50

I’ve never seen anyone make the argument that performance is not important. I have seen people make the argument that performance is less imprtant than some other property (maintainability, extensibility, legibility etc. etc.) given certain aims and constraints.

That's literally one of the excuses he debunks. Case in point: it is such a large factor on customer satisfaction and the bottom line that large companies such as Facebook would spend significant sums of time and money improving performance.

Yes, clearly in that case performance is important but is performance always the most important thing?

I read the article and didn't find it convincing, I would argue that it's clearly not always the most important thing. This isn't an "excuse" it's a calculation that teams make, the author feels that people make the tradeoff at the wrong point but instead of making that argument he frames decisions not to prioritise performance as "excuses" which is bullshit. There's always more performance optimisations one can make and there always comes a point where it just doesn't make sense to do so for all manner of reasons.

A trivial example: I have a script which downloads a few thousand GIS Shape files and converts them into geoJSON. It runs automatically once a month, usually whilst I sleep. A run takes about 5 minutes at the moment but there are a couple of things I could do to make it run in a fraction of that time but then the script would be two or three times longer and more complex, and I'd have to spend a couple of hours writing and testing code, (there'd also be some edge cases that I'd need to account for which the current setup allows me to ignore). I judge that to be a waste of time which would make anyone who has to take ownership of this script in the future's life more difficult. So that's my "excuse" and I'm sticking to it.

Re: Performance excuses debunked

#78

Post by shrimp_emoji »

gonzo41 wrote: post #73
JanneVee wrote: post #71

Earlier quoted context omitted.

OO encourages objects graphs scattering your data unpredictably in memory and modern CPU:s likes to have it's data in continuous memory area where it can do prefetching and prediction on where your data resides.

That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).

> RAM is so big these days that most databases can fit into it and be blazingly fast.

... Compared to L3 cache? Isn't that still at least 10 times faster?

That probably only matters in high performance projects though.

> the correct way to structure IF statements (Common case first etc)

But muh early returns on error D:

Re: Performance excuses debunked

#79

Post by magicalhippo »

citrin_ru wrote: post #72
magicalhippo wrote: post #13

There's often a lot of low hanging performance fruits when writing code. Need to loop over some order lines and find distinct article numbers? Use a hash-based set with O(1) access, not just a list which will have O(n). If not you'll end up writing an O(n^2) routine for no good reason, which will work swimmingly on you 10 line test order and cause grief in production. I don't think a lot about performance most of the…

O(1) hash vs O(N) array loop is a bit more complicated - for small N linear search can be faster - no need to compute a hash function, if data stored directly in the array (instead of pointers) then there will be less CPU cache misses. Exact threshold can be determined in a benchmark but the key here here is that N should be bounded - if a user can manipulate N to be huge and you have O(N^2) somewhere in your code it…

Yeah I was thinking in a CRUD setting, where I live, where you won't be doing the operation too often. In that case the inefficiency for small N is a non-issue vs the pain of a O(N^2).

Re: Performance excuses debunked

#80

Post by never_inline »

citrin_ru wrote: post #72
magicalhippo wrote: post #13

There's often a lot of low hanging performance fruits when writing code. Need to loop over some order lines and find distinct article numbers? Use a hash-based set with O(1) access, not just a list which will have O(n). If not you'll end up writing an O(n^2) routine for no good reason, which will work swimmingly on you 10 line test order and cause grief in production. I don't think a lot about performance most of the…

O(1) hash vs O(N) array loop is a bit more complicated - for small N linear search can be faster - no need to compute a hash function, if data stored directly in the array (instead of pointers) then there will be less CPU cache misses. Exact threshold can be determined in a benchmark but the key here here is that N should be bounded - if a user can manipulate N to be huge and you have O(N^2) somewhere in your code it…

In this particular case, even if performance is not concern I would use the hash map. It just reads better.
Post reply on HN